NefMoto

Hello rear readers,

I own a EOS with BWA Motor and installed "Additional Instruments"(PN 5C5919527B) from VW Scirocco into my car. The clock and the Oil-Temperature are working fine, but unfortunately the Boost Pressure Gauge is not. Its
basically stuck at zero and does not move. There are some "messages missing" according to VCDS.

I am trying to make it work be adding this feature into the ECU. Here is my journey so far:
1. Tried around with the Additional-Instruments on Bench with Arduino CAN-Shield. A Friend of mine gave me the tip to try to send CAN-Message 0x588 with Byte5 set to a value will to the trick. It did work.
2. Looked it up on Funktionsrahmen. It looks that this functionality is not implemented at all, and it always sends 0 on Byte5.
3. Dumped the binary with Kess from a friend and started to looking for Definition Files. Found some which were supposed to be "well documented" for Tunerpro, unfortunately it has not much tables. Found a documented binary + winols project here:  http://nefariousmotorsports.com/forum/index.php?topic=18618.0. Started with this binary as a start.
4. Started disassembly with IDA Pro using Basano Tutorials. IDA Pro turned to be out really complicated to use.
5. Switched to Ghidra as i had some previous experience with it. Unfortunately there is no tutorial for Ghidra + MED9.1.
For anyone wanting to use ghidra, use PPC(Big Endian) and set following registers and you are good to go:
assume r13 = 0x7ffff0
assume r2 = 0x5c9ff0
Memory map can be used from Basano Tutorial.

6. Started looking around for entry points for CAN-Bus Messages. Found "PMAXKBI_W" in WINOLS. Address is 005c6300. Used as entry point in Disassembly
7. Found Mot8Byte6 under 008043b1(by reference from PMAXKBI_W)
8. Found Mot7Byte5 under 008043a0 (by reading Basano tutorial and assuming that the CAN-Buffers are all nearby)
9. Found that the "boost pressure" which will be written there will be under 008028e
10. Got a spare ECU and tried to build up a Bench-Setup. Unfortunately i cannot write binary to the spare ecu due to the Immo being active. Need to buy BDM100/or KTAG to proceed further.

Questions so far:
1. Has anyone done it before?
2. Is there any tool which can read/write ram on MED9.1 using TP2.0? I have seen some basic scripts in python which can do it, however i would really appriciate if there is any tool which is capable of doing it.
3. Can someone confirm/decline my findings regarding adresses? The file which i am currently using is 1K0907115.

Greatings
Elias

1K0907115 is for sure not a BWA file. Anyway in 1K0907115 the codeword to enable the message is at 1C5EFB.

Why you cannot even write correct part number or upload your file? For the BWA file from other thread it should be at 1C6338...

Hello cherry,

Sorry for my manners. I should have posted my dumps with my first post. I am currently using the WINOLS map, which seems to be very similar to the one which i have on my spare ECU. At least the can-bus buffers seems to match between both dumps.

On the dump-from-winols.bin i can find A5 in 1C5EFB, however no References. On 1C6338 i can find a refence to the function which writes the boost. I suppose that i need to write a 1 to the address to enable this function
.
However i still do not understand correctly how its working
According to the "pseudocode" of ghidra the change in the dumpfile will be executed "after" the memory variable has been written. I suppose that it might have something to do with multiple runs of this function, when something else happens which will trigger the code above.


Many thanks for providing the adress. I will give it a try and hope it will work.

So my plan is for now:
1. Change the address
2. Adjust the Checksums with MED9Tool
3. Flash it to the ECU

My logger will read RAM.
Write no, but you can read all you want.
www.vehical.net

CWLDANZ  Codeword for Boost Gauge
just need correct bit enable

Hello everyone,

I made a lot of progress today:
1. Realized that i can make IMMO-Off on the spare ECU with an EEPROM reader + KESS. Did exactly that. Wanted to have a Backup-ECU if something goes wrong while flashing it into the car.
2. Dumped original ECU(which is in the car), patched the address(0x1C6338), corrected checksums using WINOLS and flashed it back.

Result:
Kind of working, but not without problems:
Before the flash, the gauge was not doing anything.
Currently it does go to 2 bar as soon as you idle the car. As soon as you start driving, it starts moving to 3 bar. It does respond to throttle, but always moves between 2 and 3 bars. I suspect that the gauge is expecting the data in different format.


My plan changed to:
1. I will try to tinker around with my ArduinoCan-Shield and try to find the values which will set the gauge to different values (1 bar, 2 bar, 3 bar).
2. I will monitor the values which the ECU is sending out. I assume that it will send the boost pressure in decimal settings(seen it in Funktionsrahmen).

0x00 = 0 bar
0x7F(decimal 127) = 1,27 bar
0xFE(decimal 254) = 2,54 bar
3. Write some function in ASM which will do the mapping

I researched the code, and it seems that it is calculated here:

Okey, i got some progress today.

1. I have installed my arduino with can-bus shield into the car
2. Created the Mapping table for the gauge by trying out different values(see boost-gauge-table.png)
3. Realized that probably the output of the ECU Function needs to be divided by 2 to output the right value for the gauges.
4. Tried to program it (see screenshots for full code):
4.1 Basically replaced the "if" with NOP(ori r0,r0,0) codes as i consider its not needed anymore. What it basically was doing, is putting a maximal value, if the value was to high. As it should not happen if you divide by 2, i removed it. Also i needed space for my code.
4.2 Basically used rlwinm which will byteshift right by 1 bit. This is basically the divide by 2.
5. Will flash it tomorow and test it. Hopefully it will work.

Questions:
1. Unfortunately i assume that the "Pseudocode Generator" of Ghidra is buggy, or i do not understand why its showing me different results for the "addi r5,r6,0x5a" code. The bytecode is same, so in my opinion it should return the same result. But on the original code, it shows me " + -0x5A" and on patched code, it shows me "0x5A". I dont know exactly what happens, because the ADDI function should result in the same "pseudocode"..Can someone please explain if its a bug in ghidra?
2. Can someone please review my code and tell me if its okey to do it this way?


Many thanks in Advance,
Elias

Just log can byte with arduino
FR shows same conversion formula as pvdkds so its just an absolute pressure

I did already a logging with Arduino.


The FR shows that MED9.1 will send the data according to following formula:
<bar><mot7byte5>
1 Bar = 100
1.5 Bar = 150
2 Bar = 200

So basically, the gauge will display correct value if you send following:
<bar><mot7byte5>
1 Bar = 50
1.5 Bar = 75
2 Bar = 100

By that i deduce that i need to divide the output of the ecu function by 2 , to achieve the result which is needed to make the gauges work correctly.

You have to subtract atmosperic pressure to get boost from absolute pressure

Then do some math or map() with arduino to calibrate gauge

Idk why you make this things so complex

Never heard that there are such problems after retrofit, i do not expect VW change factor in newer MED9.1 ecu. Btw. 1 bar on this intrument is atmospheric pressure, so it should show 1 bar at engine off.

Maybe the intrument is broken, did you check values with VCDS? Did you make output test, does the pointer work correct? Are there any coding options in the instrument?

I think its related to the fact that this gauges were never sold with the MED9.1 motors. They appeared on the VW Beetle Facelift and VW Scirocco Facelift. Both were produced long after the MED9.1 was canceled.

Nevertheless, i am 100% sure that the gauges are working correctly, as the oil-gauge is working fine and i can drive the boost-gauge with my arduino. I suppose they just changed the mapping to allow higher boost values. The original values from FR are limited to 2,55 bar(0xFF) , and the gauge can drive up to 3 bar. So it makes sense, that they just divided the value by 2 to make it work.

Regarding pointers: they are working fine.
Regarding Coding-Options: I checked but there are no related coding options in this gauges.

I did the changes however they havent change any visible value. I suppose that i havent found the correct can-bus buffer on this firmware.

Question:
Does someone know the adresses of the Canbus-Buffer on the  firmware?
I know that the one for MOT8-Message Can Buffer is starting at 008043ac. I am searching for the MOT7-Message Can-Buffer so i can modify the value before it will be sended out. I assumed that it would be at 008043a0, however this was not the case...

i think u are wrong
1K8907115L
 sold until 2018
this binary enable boost gauge 

many thanks, learned something new. I was thinking that the ECU was dropped after the Golf 6R...

1. I got a binary(1K8907115L) from http://nefariousmotorsports.com/forum/index.php?topic=14741.0
2. Loaded in Ghidra and wanted to compare the code
3. Oh boy - nothing is same between my binary and 1K8907115L. Cannot find any common adresses etc. Also do not have any Damos for that file. I stopped it here as i really doubt that i can "copy" it over from that file.
4. I really doubt that its a good idea to flash this file onto my car, as its designed for the 280PS CDL Engine and i have only 200PS BWA Engine.
5. My plan would be first of all to do some base-research...i need to find the adresses of the canbuffers on my binary to move forward with this project. Idea is still to "reprogram" the code which is writing the can-message.


Questions so far:
1. Does anyone adapted the 1K8907115L Binary for BWA motor? Maybe someone did already, however its very unlikely that someone done it.
2. Does anyone know where the can-buffers are located on my binary?

Btw your Scirocco instrument is not from Scirocco, but from beetle. Not sure if there is any difference in CAN data.

Which bit(s) from CWLDANZ did you set? Set bit 0, 1 and 2 -> 07h, in the Scirocco file it´s at adress 1D43E5.

+-----+---+-------------------------+
| Bit | | Bedeutung |
+---------+=====+===+=========================+
| CWLDANZ | 0 | 1 | Anzeige des Ladedrucks |
| | | 0 | keine Anzeige |
| +-----+---+-------------------------+
| | 1 | 1 | Saugrohrdruck |
| | | 0 | Druck vor Drosselklappe |
| +-----+---+-------------------------+
| | 2 | 1 | Hüllkurve |
| | | 0 | Messwert |
| +-----+---+-------------------------+
| | 3 | 1 | Relativer Druck |
| | | 0 | Absoluter Druck |
| +-----+---+-------------------------+
| | 4 | 1 | Druck ungefiltert |
| | | 0 | Druck gefiltert |
| +-----+---+-------------------------+
| | 5 | | frei |
| | 6 | | frei |
| | 7 | | frei |
+---------+-----+---+-------------------------+

Not sure why bit 2 is set, but this is how it´s done in the file. Maybe the value is calculated, because there is no map sensor after throttle. Bit 3 should reduce value minor 1 bar. Did you read the FR???

Edit: Ok, i think not all MED9.1 FR does not contain this informations...

Hello cherry,

First of all, in my binary the value of CWLDANZ is only used once and compared only against 0. I havent seen any other checks(using Find-Reference in Ghidra). So putting any value is enough to enable the Can-Message. I assume that newer binaries have a different logic , and may use the value like you described.

I made some progress by hacking together a RAM-Read/Write Tool for investigating the adresses needed. The tool itself can login into the ECU using SA2 Algo and then should read/write ram. Currently i am investigating this read_data_by_identifier and dynamically_define_data_identifier

Besides your reverse engineering, did you try it?

Hello everyone,

With the help of basano threads, i made a ram-reader for MED9.1. However i havent figured out the RAM-writing yet. It seems that the ECU is locked for RAM-Writing.

The tool itself can be found here:
https://github.com/EliasKotlyar/MED9RamReader/

@cherry : Will try it out(setting bits) and report. Now i have the right tool and can figure out all the mysteries of the ECU.


Besides, can someone tell me which values the Boost-Gauges should display when installed normally in a car? Is it "Boost Pressure,(specified)" or "Boost Pressure,(actual)"?

Greatings
Elias

No $3D service on VAG MED9 and no $2E for Dynamic DID iirc.

Okey,


@cherry: I tried and it did not give me any different results. It seems that the byte do nothing else as enabling the message.

I tried around with and found out that the Boost Pressure Variable is located here:
0x007fc99a

It seems that i need to create a map function, which will map the values of the boost pressure gauge into the values which are accepted by the boost gauge. Will try to do it...

You don't need to map anything since it's linear.
It's enough to have a factor + offset.

Also stuff is referenced via SDA and TOC. Might be a good idea to set those properly in Ghidra if you haven't already.
Not sure why you need the RAM reader. It's not neccessary for what you want to accomplish. Reading RAM is open via $2C on these anyway.

In fact this whole thread makes me scratch my head. This modification is super simple.
If the codeword doesn't do it, find where it's written to CAN (xref some references of other things written into this packet) and just modify what's written.
You can use any file for which there is A2L. Scripts for IDA to populate vars based on A2L are also posted.

You can use direct signal from boost sensor to arduino. Install arduino between car canbus and your beetle gauges. Make a arduino program which will filtrate messages with zero boost bytes, add boost pressure data to it and send it to beetle gauges.

Perfect example of making something super simple insanely complicated and failure prone.
An Arduino is not:
a) Extended temperature rated
b) Not vibration proof
c) Your connection won't be shock and vibration proof either

No, don't do it. Modifying 5-6 commands in ASM is 10x easier, and it's not gonna make your clocks stop working randomly.

I finally managed to solve my issue....It was indeed as PRG said only a few assembler commands but ...getting there was a lot of pain. The coding part was really fun, but the ASM part was weird and complicated.

As some "byproducts" i have coded a whole tool which is capable of reading/writing memory, seeing measuring blocks etc. Without it, it would be a lot more pain, as it would not be possible to see whats happening inside the ECU and modifiying it. It can be found here:
https://github.com/EliasKotlyar/MED9RamReader

Also i coded a lot of small scripts for automatically tagging MED9-Stuff into Ghidra:
https://github.com/EliasKotlyar/Med9GhidraScripts

The whole script can be found here, if someone wants to patch his binary:
https://github.com/EliasKotlyar/Med9GhidraScripts/blob/main/PatchBoostGauge.py


As extra tip for someone who wants to do similar things in the future:
Start with the measuring blocks. It will allow you to see how VCDS is dealing with variables, and therefore allow you seeing the scaling of the values. The absolute pressure which i have been using, is not scaled with some constants (which i would expect) but rather with code. The code goes like:
(just an example). Do not use A2L-Variables as they are heavily edited before its transmitted into VCDS.

If you have an a2l then it makes 0 sense to do any of this.
The FR tells you which variables go into which CAN packets (it essentially defines the CAN matrix) and you can just look up what should be there and in which location.
FR's are easily found for MED9.

Good job on coding this stuff, but you made something 100x more complicated than it could have been.
But seeing what you did it was not about the result for you but more about the journey. Which is very good and this knowledge will serve you well in the future :)