So of course playing on a databus is no fun without knowing who is there.
You need to know the unique addresses of all the devices.
They are like the names of your friends - the name or the address is their identity, and with the address known you will get to know the device well, in fact you will learn them off by heart.
Just like many humans, the Volvo P2 devices have 3 x identities. in fact sometimes more.
Let's go through them, remembering always that I am talking about a P2 MY2009 XC90:
1. The static ECU id
Every module in the car is assigned 1 of up to 256 possible single byte static very important ids, from 0x00 to 0xFF. Well actually, 0x00 would never be assigned, so that's 255 ids. These are used by the diagnostic device such as VIDA to address the module directly. See my last blog post for where to find these ids in VIDA - they are hidden in plain sight.
These ids are static because the diagnostic system needs to know who it wants to talk to regardless as to what car is connected.
As an example, we'll use the friendly and very clever CEM (Central Electronics Module).
The CEM has the module id of 0x40 on the low-speed CAN bus and also 0x50 on the high-speed CAN bus - yeah, then CEM is rather special.
However, these are not the frame ids (or message ids) used on the CAN bus.
2. The high-priority message id
On the CAN bus every message has a message id. These are the ids that you see in every CAN bus monitoring tool
When a module, like the CEM, responds to a diagnostic message, it does so using a special CAN bus diagnostic message id, also known as a diagnostic id. This diagnostic id has a higher priority that the normal CAN bus messages, so that it can jump to the front of the queue.
The CEM has a diagnostic message id of 0x00800003.
The response includes an acknowledgement of the request, and the data requested. Interestingly, these messages also contain the ECU address of the device sending the message. We'll study response formats later.... maybe.
3. The normal message id
On the CAN bus each device sends a message with a unique message id. As the message id also determines the priority of the message, the developers (or their tools) very carefully assign these message ids based on the message content and it's priority, not based on the device sending the message. Thus a CEM can, and does, send multiple messages with different message ids. Actually, once you start to think of the CAN bus id as a message id, and not a unique device id, you start to understand the way the CAN bus works a lot easier.
In a Volvo, due to the software used by Volvo designers when designing the bus as a realtime bus system, the message ids vary across model years (MYs) and thus may not be the same in a 2004 XC90 versus a 2009 XC90.
But luckily some messages retain their ids across time and this makes our job a little bit easier.
Also some messages have similar, but not identical, ids, also helping us to understand them.
As an example of message ids, the SWM (Steering Wheel Module) sends data in a few different messages, with one message for the audio buttons, one for the cruise control buttons, and I also believe one for the control stalks.
Finding all the message ids is quite tedious. There should be a clever way, and I'm thinking about that.
But currently, I'm doing the slow, hard, log the bus and figure out who is what by using freqeuency analysis and studying the data content. It's a bit like Neo seeing the matrix....
No comments:
Post a Comment