4)   By trial and error I discovered that not only do you need to put your own CANBUS ID in a spare line in the flash table, you then need to read that table entry. I’ll try and explain the code snippet below. Basically it’s saying load #1 into a register (#1 means first row of the flash table), then call a function that does the reading 585C2C. Then load #2 into a register (#2 means the second row of the flash table) and call the same reading function 585C2C. Repeat for each row of the table. This is the important bit, you don’t need to mess about with anything else, just give the row number to the function 585C2C and it does everything else for you. The data bytes will pop out in the RAM table. I found the code that reads the table rows by searching on cross-references to the configuration table (at 0xA09F4).



5)   So where is the best place to load and call this reading function? In my S3 flash, table row #7 is free and thus not called anywhere (there are no lines of assembler that refer to row #7). I compared that against the A6 bin where row #7 is actually in use. I saw that in the A6 bin, row #7 is called each time after row #1. So what I did in my S3 bin, each time row #1 is loaded and passed to the function, I added in a couple of lines that load row #7 and pass it to the function as well. I only had to add 12 lines of assembler. The OEM code calls table row #1 three times, I don’t know why but I copied it faithfully.



6)   There are also codewords (CW_CAN_R, CW_CAN_RA, CW_CAN_RB, CW_CAN_C) that turn on and off the monitoring and reception of CAN messages, but these messages actually need to be compiled into the flash to begin with. What I’m doing above is adding messages that never ever existed in the first place, they weren’t compiled in and there’s no lines of assembly relating to them. Thus the code words don’t really apply – it’s happening at a layer below any of that. Worth mentioning as well is that there’s no monitoring or message timeouts resulting in fault codes either – if one of my bespoke messages goes missing, well it’s gone. All I did was patch in a few lines that piggyback the reading of table row #7 on the back of another table row read. That’s why there are far more lines of assembler in the A6 bin to read row #7 than just my 12 lines. I think all the other code takes into account monitoring and timeouts and codewords, but I put in the bare minimum to populate my CANBUS RAM table. It’s very simple.

Here’s how I implemented it

I used CANBUS ID 44A. This was free (unused) in my car and as far as I can determine, is related to the automatic transmission (read the FR, sections CAN_CONF and CANECUR). I have a manual, so I think I’m fairly safe.  

To tap into the powertrain CANBUS, I wanted a way that was non-invasive and didn’t require any modifications on the stock wiring harness. I wanted to be able to unplug any modifications in a matter of minutes if I needed to revert back to 100% OEM. I also wanted the diagnostic port to be free so I could use data loggers and diagnostic tools like normal. The CAN gateway was the easiest place for me. In my S3, it’s located just behind the glove box and is pretty straightforward to get to. I made a little pass-through box. Just unplug the 20 pin wiring harness connector from the gateway and plug it into the pass-through box. The pass-through box in turn has a short length of cable that plugs back into the gateway. The pass-through box also has a DB25 connector that all the buses (powertrain, infotainment, diagnostic, cluster, convenience) are available from. You can buy the plug housings from VW/Audi, but for the sockets I got a couple of cheap eBay CAN gateways and lifted the sockets off of them. To make the little stub cable between the pass-through box and gateway, I sourced the crimp pins from Farnell and got a wiring loom shop to crimp them up for me using their Tyco/AMP hydraulic tooling.

The software is very easy, in fact I used readily available libraries for the Seven Segment display and incremental encoder. The encoder has a detent, so when you twist it there’s click to provide some tactile feedback. When you turn the encoder dial, the first data byte of the transmitted CANBUS message changes. One click clockwise -> 01, another click clockwise -> 02. Turn it in the other direction and it decrements. One click anticlockwise -> 01, another click anticlockwise -> 00, another click anticlockwise -> FF, another click anticlockwise -> FE (two’s complement representation of negative numbers). The Seven Segment display shows the scaled value of what’s being sent in that first data byte. I’m transmitting eight data bytes, but only the first has a value and the remaining seven are zero



Pulling it all together then, I wanted to use this to change the output of KFZW and KFZW2. I added a bit of bespoke assembly that combines the output of the timing map with the correction value received over the CANBUS. This combined value is then used by the subsequent ecu assembly code, effectively as though the map value itself had been changed. There are five chunks of assembly – the original code has x1 reference to KFZW and x4 references to KFZW2. All I did was add code that takes the output value whenever KFZW/KFZW2 is read and combines it as described above.



Looking at an extract from a log of the memory locations, you can see the original output of KFZW, the value received via CANBUS and the new value (sum of original value and CANBUS value). I was storing the register values in RAM so I could log and check my workings, especially since the firing angle can be both positive and negative (BTDC and ATDC) and negative numbers means two’s complement maths. I didn’t want to mess it up, but all it needed was sign extension 

You’d log rpm and load and CF’s, turn the dial (which  increases the amount being added to the original map output) which increase the firing angle advance. Check CF’s or torque. If the CF’s are good then you can permanently add this much timing to the cell (next time you flash), else back the dial off a bit until things look better (new map entry = original map entry + correction).

In summary, this was a neat way of changing variables inside the ecu without too much hardware effort (extra wires or pins on the ecu). I used KFZW / KFZW2 as an example, but I’ve subsequently discovered there are many more timing maps than just those two. The same principles could be applied to other things, like LDRXN or even having a little toggle switch on the CAN node. Flicking the toggle switch could result in a RAM location being set to zero or one and activating or deactivating a function (ALS/NLS) or even hardware like cooling fans. Use your imagination 

IDA project attached, plus before and after versions of the bin so you can see what I changed.

Installed in the car

This is so awesome!

A lovely, detailed write up too, well done sir!

You know, I just love these kind of things! Well done David!
I will try this approach using my NXP setup.

What is TP20? For me beeing an old hw designer, that is a testpoint

Ahhh...of course...