A client brought me a Golf4 he just bought. No ideas who mapped it or what chip/injectors are in it. It has a neuspeed supercharger kit in it. I took it for a short drive and it was detonating like crazy. I pulled the ECU and dumped the ROM.

It's a 06A906032FQ. I've been hunting for a stock ROM for comparison. No luck yet. I searched high and low to find a ROM/DAMOS/A2L pair that was similar. There is lots of 1.8t stuff but nothing for the little NA cars.

So I got a 06A906032MT from the local breaking yard and set about comparing them. I then used a 1.8t ROM and imported and translated the A2L for table descriptions and math. There many changes and I'm not sure which are from tuning and which are just year to year differences. I'm still waiting to find a 06A906032FQ ROM/ECU.

Some of the tables are proving very difficult to find in the two and I don't want to invest weeks of work reverse engineering both in IDA Pro.

Does anyone have other suggestions on how to attack this problem?

Thanks, that is incredibly helpful. The firmware appears to be only slightly modified. Since I don't often work with the ST processor I didn't pull them into IDA but it looks like a few small changes were made and a small routine was added to the end with the firmware checksum being updated too. I'll spent some time and see if I can identify what items were changed. Are you aware of any A2L or mappack available for this software? The thing I appreciate about Bosch is that there is often factory data available so the entire mapping and explanations of the strategy are known.

Are you aware of a way to read/clone the EEPROM on this type of hardware without removing the chip? Not the end of the world if I have to but the easy path is always better.

I didn't realize that their tune was _that_ bad. The firmware changes seem very small. Perhaps they've just prevented the ECU from being read via OBD2. I see 1 extra routine and a few bytes patched which I assume are probably a function call. I don't know ST assembly well enough to recognize the byte codes in a hex editor.

So I spent a bit of time on it. Found a number of the maps. For ones with external axes they seem to be a bit harder to find so please excuse the errors in 2h of work so far.

I think with fuel they're using an adjustment table like VE and making sure it kicks out of closed loop at higher loads. I have to read the functions definition file to get more acquainted with the bosch way of doing things.

Their ignition maps make no sense. The stockers make sense for an NA engine but why would you add a ton of timing at the top end where the blower is going to heat the crap out of the charge? (ignore bad axes). I'm thinking of just fixing the timing and making sure the fuel is reasonable. I have no idea what injectors they put in this thing but the injector scale KRKTE seems untouched.

The axis for KFZW are:

0x130B6 rpm
0x1310C olad

Spent a little time on the axes. Since I started digging into this I found a TT map where the calibration data isn't all that different. This Bosch stuff is significantly easier than what I'm used to.

Looking for KFZWOP, KFZWOP2.
I believe the air charge is at 16438 and the nmot is at 130B6.

The air charge is easier to find because its neighbours are identical and there aren't too many axes of size 0x0b. The RPM is a bit more of a challenge.

Here is how I did it. Since the axis structure starts with the size, I knew that I was looking for a 16 item axis. 16 bit also. So the axis needs to start with 0x0010. I located it on the TT map and tried to find the correct offset. The TT map has more axes but looking at it visually I think I got it right.

I'm assuming on this the air charge goes up to 100% since it's an NA engine and the TT goes up to 160 because of boost. Once I make the timing a bit more sane I'll stick it in the car and see if I can log what it's actually doing. The map doesn't need to be perfect, just stop the kid's engine from throwing another rod.

If it were my time at the rodeo the topic on how to tune and engine might be a concern.

Back on topic.

The checksums are not an issue.

The LAMFA table is messed in stock form both for the TT and the stock Golf. I've verified the axes in several ways. The axis is documented as mrfa_w. That comes from the larger of KFPED or FGR (cruise control request). The table itself doesn't make sense because it appears to request a slightly rich condition at low throttle but not high throttle. The Neuspeed map sort of tried to remap it but the axis is again wrong since you expect it to be searched in a strictly ascending fashion.

Below the single map image is what neuspeed did. The double map image is the stock golf and the TT file I'm comparing against.

The S4Wiki says: When requested lambda is <1 (richer than stoichiometric), the fueling system will go "open loop".
This makes sense but if the description were complete then the car would almost always run open loop.

Can anyone point out the main tables needed to get it into open loop?

Thanks for the correction. The A2L data is in fact wrong and the offset for the axis is off by 1. Correcting it shows valid info now.

To address your first point. The target lambda has to have come from somewhere. Understanding how target lambda is derived and how open loop is selected should give the ability to change it. I'd be surprised if they hard coded all the targets to 1 but if I have to I'll patch the firmware I can.

It could be possible to push it to component protection enrichments when under boost. I could probably even disable closed loop entirely and fatten it through the MAF function. Or using their VE table. There are many ugly ways to accomplish the result. The first order is to pull some timing so it stops detonating then look at the fuel and see if there even is an issue.