The code patches are first developed by loading the software from a powertrain control unit into a disassembler such as Ghidra or IDA Pro. From there, the processor specifications, memory map(or sections), base address and other important loading information is fed to the disassembler to correctly untangle the binary into a format which shows us the underlying logic system.

From there, we can follow the logic to find references to data areas where particular maps are referenced, such as those to control ignition timing, boost control and the likes. In our case, and for the example used here- we have created a ‘hook’ into the program flow which sets the axis and data area for a map used to control the wastegate actuator during open loop boost control.

Usually, enabling open loop boost control will allow us to use a factory setup referencing a 6×6 table of 36 data cells, with very little resolution or control. With our patch we are able to not only increase the resolution to 15×10 (150 data cells), but also enable other conditions such as offsets based on load, torque and even different referenced maps depending on gear. This is something you would usually find only in an aftermarket engine control unit.

These features can be enabled on almost all OEM controllers, and we have no issue in porting the solution to any platform should the requirements need to be met -> in my mind mostly for motorsport oriented purposes.

The capabilities and performance that can be extracted out of an OEM powertrain controller in modern times are much more cost effective and allow for a safer more refined control in the hands of a calibrator and software engineer who know how to best optimize the system.

WinOLS view of both the OEM calibration map, and the LM patch
Ghidra view of the patch hook