|
Title: MED9.1 Communicating with peripherals (e.g. cluster) Post by: Basano on June 06, 2014, 08:25:50 AM Hi guys,
There’s another neat bit of information contained within the ram. The ECU transmits a number of CANBUS messages on the bus which are picked up by other modules. The transmitted messages are described in the FR in section CANECU 1.240.0 CAN Sendebotschaften und Signaldefinitionen and section CAN_CONF 1.50.0 CAN-Kanalbelegung in der MED9. You really need the FR as a reference for this ;D Bosch VAG MED9.1 FDEF (http://nefariousmotorsports.com/forum/index.php?topic=812.msg10309#msg10309) For example, in Message ID 280 (Motor 1) bytes 3 and 4 contain the engine rpm (nmot_c). This information comes straight from the FR. Disassembling and looking at the code that sets bytes 3 and 4 will lead you to the variable that holds nmot_c. This is how devices like the instrument cluster know what rpm to display – they get the message with the rpm over the CANBUS. (http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=6172.0;attach=9606;image) (http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=6172.0;attach=9608;image) By searching on the CANBUS message ID’s in the ram dump, I came across a section of the ram that contains the message ID’s and payload. Ergo, these are the message buffers that contain the data that will be sent out by the ecu. By disassembling in IDA and looking at the cross references that point at this section of ram, you can locate the variables that hold the data to be sent out. This was in the external ram which starts at 0x800000, so all the ram address in this particular ram dump are offset from this (0x0 = 0x800000, 0x1 = 0x800001 etc) External_RAM_dump.bin (http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=6172.0;attach=9612) (http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=6172.0;attach=9610;image) CANBUS Message ID Payload Title: Re: MED9.1 Communicating with peripherals (e.g. cluster) Post by: Basano on June 06, 2014, 08:30:21 AM What about the other direction? Changing nmot_c to change what’s transmitted out?
I was a bit wary about changing nmot_c directly. Although nmot_c will indeed be passed to the message buffer for transmission, what about other places in the code that may depend on nmot_c? The results could be unpredictable. So instead of changing the variable nmot_c, I decided to change the message buffer instead. Just before nmot_c is written to the message buffer, I insert my own value thus: Original flow: nmot_c -> general purpose register -> message buffer Modified flow: nmot_c -> general purpose register -> my_own_value -> general purpose register -> message buffer I limited my changes to the message buffer to when the engine was not running (B_nmin). Remember, although I’m not setting the variable nmot_c within the ecu, I’m still going to be sending out a CANBUS message with a modified value for nmot_c. The cluster should see this and move the rpm needle. Other nodes may also think the engine is running when it’s not… So I played it safe and put in some conditions – engine not running (B_nmin) , brake pedal pressed (B_br), clutch pedal pressed (B_kuppl). The result is a little routine that flicks the rpm needle from 1000 -> 2000 -> 3000 -> 4000 -> 1000 every time the clutch pedal is pressed and released (plus engine not running and brake pedal also pressed). All I’m doing is overwriting bytes 3 and 4 in that message buffer. This code is specific to my bin and location therein. I’ve chosen the General Purpose Registers and RAM addresses _very_ carefully to avoid clashes. It took me ages and I bricked my ecu more than once. BDM was my friend to recover here. Use it as a guide by all means, but it’s not intended as a straight copy/paste exercise. If it all goes horribly wrong, you have been warned… This is my entry point into the code. I replace the original instruction at ROM:004F7B60 with my own instruction which is a jump to a free area ROM:0047C750. The penultimate instruction in the free area will be the displaced original instruction and the final instruction will be another jump back to the original code. General purpose register r30 is what I’m going to ultimately overwrite as explained above. Code: This section is the original code And this is the new code that increments a counter. There's a section in here where I store the count byte in non-volatile ram. Directly after that I calculate a checksum of the ram mirror block where I've stored the byte. This is so the value will be comitted from the ram miror to the eeprom. This post has more details about the ram mirror. (http://nefariousmotorsports.com/forum/index.php?topic=6159.0title=) Code: This is my new code I added in free space Little video attached to show you the end result MOV_0001.mp4 (http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=6172.0;attach=9613) Title: Re: MED9.1 Communicating with peripherals (e.g. cluster) Post by: max974 on October 22, 2019, 02:22:00 AM Hi, thanks for all you done for this community.
i'am on this part for a long time, already find my Free RAM for all the multimap etc... But still don't find how or why you choose the ROM:004F7B60 Adress to add your jump to the cluster code ? My file is the 8P0907115AB one. Can some body tell me where to put this jump or how to fine the good place for the cluster check? Thanks |