RomRaider

Digging away inside my ROM there seems to be a 'configuration' byte in RAM that can be used to turn on/off the following on the fly. Some folks may find this useful for setting up their car and/or tuning. The default value for all bits is 0.
- Bit7 - setting to 1 disables various items relating to the speed sensor (such disabling speed limiting). It also has some other effects relating to the speed sensor I haven't fully investigated.
- Bit6 - depends on your ECU logic for calculating Knock Correction. If your ECU has the calculation style that uses IAM, then setting this bit to 1 disables FBKC advancing/retarding. If your ECU has no IAM, setting this bit to 1 does nothing.
- Bit5 - depends on your ECU logic for calculating Knock Correction. If your ECU has the calculation style that uses IAM, then setting this bit to 1 disables FBKC entirely. If your ECU has no IAM, setting this bit to 1 will disable all Knock Correction.
- Bit4 - setting to 1 turns off Idle Target AFR Compensation
- Bit3 - setting to 1 stops Open Loop / Closed Loop transition
- Bit2 - setting to 1 disables CPC valve compensation
- Bit1 - setting to 1 disables something that doesn't exist in my ROM so I don't know what it is
- Bit0 - unused

The RAM byte is initialised to a value stored in ROM (0x00) during initialization. It doesn't look like the RAM byte is changed once the ECU is operating, so it should be able to be manipulated at any stage like any RAM value (eg: with the SSM Address Write function).

I have looked in another 2005 ROM, and found the configuration byte. I also found it in a 2009 ROM. I couldn't find it in a 2019 ROM, but that's not surprising given the coding has probably changed a lot over the years.

Finding this configuration byte is the literal needle in a haystack, but the following worked for 3 ROMs:
- First search the entire ROM for 0xE435. There should only be a few instances.
- One instance will be inside a function that starts by calling three functions. The third function call passes an argument of 0x35 (hence the search for 0xE435). The second function call is the one that returns the value of Bit7 of the configuration byte.
- Go into the second function. This will be performing an 'AND 0x80' operation on a RAM address. The RAM address is the configuration byte.
- Go to the configuration byte's RAM address. You should see 1 XREF which is a function in which it is written to (when it is initalised to 0x00) and a number of XREFs that are functions in which the various bits of the Configuration Byte are returned.

Once you have the RAM address, you should be able to write to it using the Test App in RR editor, and you should be able to do this while the car is running. Note: I haven't yet had a chance to try this on a vehicle.

I'd be interested to hear if anyone finds it and tries it.

an example is it possible?

Searching for 0xE435 sometimes works, sometimes doesn't.

If it doesn't work, another method is as follows. This relies on you having definitions for extended parameters, specifically Feedback Knock Correction E39 (FBKC).
- Go to the RAM Address for FBKC. You will see a number of XREFs that write to FBKC and are all in the same function. This is the main function where FBKC is calculated. Let's call this Func_Calculate_FBKC.
- Go into Func_Calculate_FBKC and have a look for where FBKC is set to a zero value. Find where it is set to zero if a byte value is equal to 1. Find where this byte value is set via a function call at the start of Func_Calculate_FBKC. Go into that function call.
- Go into that function call. This function will be performing an 'AND 0x40' operation on a RAM address. The RAM address is the configuration byte.

Attached are two examples, one using the 0xE435 approach and another using the FBKC approach.

I know this post is old, but I decided to check this out on the EZ30 ROM D0XJ001M and was able to find this RAM byte @ ffff64bc. The EZ30 ROM actually writes to this byte value instead of all code just being reads, copying in a value from calibration @ c12ec.

Thus, in the EZ30 its possible to permanently set the value of the configuration byte via calibration. Enabling permanently disabling said features above.

Very interesting find.

Excellent, glad it was useful! Did it have the expected effect?

Yes, permanent changes should be possible in all ROMs, because the RAM byte is initialized with a byte value from the ROM.

Yes to some extent. I noticed D0JX001M doesn't support all the features of the "byte" per say. Though the ones it does support work as intended very nicely. An example of one of the unconnected features is the Can Purge system, which totally ignores Byte 1 despite code being present to interact with it. Other things like the FLKC lock or disable bits work soundly.

-Rob

Any hint where those values could be stored in the ROM?

I hacked a way to disable Knock Control when under certain circunstances (Launch Control, etc), however if there's already a function coded in the ECU for those, should be easier to manipulate without having to jump to a hacked subroutine.

My approach changes the FBKC & FLKC Retard values to zero (from it's default -1.4 or anything else configured on the ROM, those values are defined already), and changes the minimum KCA/KCR to enable IAM changes (usually around 3.5 BDTC by default) to something higher. That way I'm able to disable any kind of Knock Control (FLKC, FBKC, IAM) when certain events are triggered.

Best regards

Hey riksk,

If you have found the RAM Byte via the method proven above, there should be an Xref to a small function that sets its values to a matching byte in the ROM. The remaining functions only read interact with the RAM byte (To check its value).

Might be able to assist if you provide your ROM ID.

-Rob

Yep, what @MidnightTuning said is spot on.