coulomb wrote:I've been reading the CMU firmware. ... In fact, it seems to me that this happens automatically any time that there is a certain type of error (I can't be certain about what type of error, and it was some time ago I that I found this).
Automatic numbering like this seems unlikely - by what mechanism would they acquire consistent numbering when they left the factory ?
If I'm right, they acquire their IDs, possibly every time they are reset, by their position in a daisy chain of special signals for that purpose:
I'll be the first to admit that the details on this drawing are staggeringly light. It's a study in minimality.
So there is this packet that is handled by Uart1 on the CMU processors, with 5 bytes; some sort of packet ID in the first byte, three special bytes, and a checksum of these three bytes in the last byte. Somehow, the number of zeroes in this packet determines the CMU ID. There is a table with an offset (0, 1, or 2 for the second, third, or fourth bytes respectively), and a mask that is one of 0x3, 0x0C, 0x30, or 0xC0. So pairs of adjacent bits are used; if the mask ANDed with the appropriate byte of the packet is zero, then this entry in the table determines the ID. My guess is that the CMU after "grabbing" an ID adds another pair of zeroes and sends it on to the next CMU. The third byte in the table (after the index and mask) is the CMU ID. I note that the entries in the table are ordered 7 8 9 10 11 12 1 2 3 4 5 6. So presumably the daisy chaining of this special CMU ID signal doesn't follow from most negative CMU to most positive, it starts in the middle with CMU 7.
If CMU_03 on my car is in a different location to your car how does that help with diagnostics ?
Sure, that's no good for anybody. But if I'm right, that will never happen. And copying of EEPROM contents should not be necessary, at least for the purposes of getting the CMU IDs correct.
I'm sorry to say that I haven't found any code yet that seems to be reading the EEPROM. There is a hardware device in the processor called the Clocked Serial Interface, which can handle the required 16-bit serial "characters". But it doesn't seem to talk to the EEPROM, at least at this stage.
There appear to be programming pads for the eeprom on the boards - much more likely that as the board is assembled on the production line a pin probe is attached to program the Canbus ID's.
Certainly, important data is written to the EEPROM when the CMUs are manufactured. My speculation is that calibration constants may live there.
Check the speakev thread I just linked to - Rupert was able to dump the contents of the eeprom which holds the Canbus numbering and while he wasn't able to overwrite it (yet) we think that's just because he forgot to erase the cells before writing them.
Physically moving the old eeprom onto the new board is another approach though, which is what he has successfully done.
Fascinating stuff; thanks for the link. I'll be watching that SpeakEV thread.
I've seen a list of BMU connector signal names somewhere; perhaps from a hand written piece of paper, perhaps from @Kiev. If anyone can point me to it, I'd be most grateful.