Tools for patching P59 code

[NSFW]

I wanted a low-effort way to integrate custom code changes with a factory .bin file, so...

https://github.com/LegacyNsfw/12587603_Patches

What's working so far:
* write assembly code in the "patches.s" file
* use PATCH_*_START and PATH_*_END labels to declare patches
* use the "patches.ld" file to indicate the addresses that those patches should be written to in the .bin file
* assemble and link with GNU m68k tools
* run firmwarepatcher.exe to apply the patch to the .bin file and update the checksums

Some simple conventions:
* The flash block at 0x900000 has the additional code
* The flash block at 0xA00000 has the additional data (it's basically a new calibration block)
* Replace a table-lookup instruction with a jsr and a NOP, where the jsr points at new code in the 0x900000 block.

Next steps:
* support C compilation, for more complex patches (unless the code gets too bloated?)
* compile/run a "test.exe" console app with unit tests for complex patches
* maybe find an elegant way to support multiple target OSes - mostly just need OS-specific RAM address declarations in a .s file, and an OS-specific .ld file.
* change the OS ID to something unique, and have PCM Hammer flash the new calibration block when it detects the new ID

The only actual patch right now is just something to toggle between the stock end-of-injection-time table and a "low MAF" version of the table, so that my car runs smoother in cruise and doesn't smell like fuel at idle (because the low-MAF table delays the fuel squirt until the exhaust valve closes), but it also doesn't lose 30whp at full throttle (because the stock EOIT table is used above 50 g/s). It's pretty trivial but it was enough to validate the patching tool.

[AngelMarc]

You care much about custom ECU hardware? Even after I test my code beyond just the bench, I'll be looking for others to test it.
I don't have a PCB design yet. My test circuit will be very easy to break.
My code has per RPM EOIT settings. The hardest part for tuning is microseconds per degree at given RPM. Could have a curve instead of a step if you wanted. No MAF though.
Was it MAF because you think that's best, or because that was easier to implement?

[antus]

I'd suggest ASM over C, because there are 2 things you need to avoid exceeding for PCM stability. That is run time in the main loops or interrupt handlers, and max stack depth. C might work but it's likely code will be bloated and you'll be more at risk of exceeding one of these limits at run time with the heaver code, which could potentially cause missed events or crashes. If you need C you would be best to spend time looking at the compiler flags to reduce any use of the stack if there is any, and optimize the code as much as you can.

When I added the CRC32 code to the flash kernels the code was too difficult in asm (for me) so I wrote it in C, and found it was less than half the size and a lot more understandable with -O2.. then I reverse engineered my C code output with that level of optimisation and hand optimised it further and back in to assembly for inclusion in to the assembly kernel. That was a pretty good workflow in the middle ground. Can validate the code in C a lot more easily, and still end up with tight m68k assembly.

[AngelMarc]

With enough documentaion and/or source code... or people sharing their work, could rewrite everything.
Need info on configuring the delco CIC chip over SPI(24x/4x/3800 dual wheel, waist spark or not), and getting it's sync data over SPI, then addressing analog and digital IO (is it as simple as memory mapped IO), then some work with timer cascading because it not 64 bit like Pico's microsecond timer, then something as simple as my code might compile in C. that gets rid of a lot o shit. I think the CIC is more or less solid state distributor like the 3800 coil pack, but integrated into ECU but doesn't have the coil drivers in ECU, because "smart" coils, so that's another change. Sure that's oversimplifying it to an extent. Most people interested probably want most of the stock stuff left in though.

[NSFW]

@antus That's a great point about hard deadlines for the scheduled code. I'll have to keep an eye out for that.

@AngelMarc I'm sure it's possible to reverse engineer enough of this code to make it do anything, but at some point it makes more sense to start with something that is open-source to begin with, like Speeduino or rusEFI. Honestly that would also be a more rational approach than what I'm doing here, so don't get me wrong, I realize it's not entirely about what makes rational sense.

On a related note, I'm in touch with a guy in my area who thinks it should be straightforward to make a board where we can solder a P01/P59 connector onto one side, and put rusEFI hardware on the other side. Hopefully I can make good progress on this before he makes progress on that, because it sounds like it would be a very big distraction.

[AngelMarc]

For me, I want my own code on rock solid hardware without needing to source all the ICs, order a custom board, etc. with potential revisions....
P01/P59 seem like the most likely to get to that point of figured out. E38 or E67 maybe. Hell, I'd use a TCU if one is sorted out enough and has the IO count needed.
i can afford time sinks, but not money sinks.

[antus]

Just speaking to the safety angle, this is an interesting read. https://www.edn.com/toyotas-killer-firm ... sequences/

Some exerpts:

Toyota claimed only 41% of the allocated stack space was being used. Barr’s investigation showed that 94% was closer to the truth. On top of that, stack-killing, MISRA-C rule-violating recursion was found in the code, and the CPU doesn’t incorporate memory protection to guard against stack overflow.

Two key items were not mirrored: The RTOS’ critical internal data structures; and—the most important bytes of all, the final result of all this firmware—the TargetThrottleAngle global variable.

Although Toyota had performed a stack analysis, Barr concluded the automaker had completely botched it. Toyota missed some of the calls made via pointer, missed stack usage by library and assembly functions (about 350 in total), and missed RTOS use during task switching. They also failed to perform run-time stack monitoring.

Obviously our flash kernels don't have to worry about any of this. But patches to the OS do. Now I am not sure how this can be done correctly. I think most people just patch away and keep it minimal and watch if it looks like it works or not. In most cases, it does. End of story. But that Toyota example is a sobering reminder of what happens in a worst case example with a edge case that is not obvious and hard to trigger, especially with electronic throttle. I don't know how its going to break, I don't think you get a standard error code, you'd probably have to put a longer and longer delay in the code path and then drive the car in safe test circumstances until you cause it to break and then see how that looks. You'd need to be off-road and have a way to cut the engine in hardware, like cutting power to the ECM just incase you do get a runaway situation.

[kur4o]

That might explain auto accelerating priuses.

As long as gm related code that have very strict memory usage and stack usage across their code from the very early 90`s pcm.

Adding C compiled code that don`t care about it may cause real problems. Some assembly check and optimization will be needed for sure, if time critical components are patched.

[Tazzi]

I typically find either running a debugger to step through code and see where the stack is, or even outputting a debug message to the communication line helps with validating how much space is being taken up.

[AngelMarc]

Software controlled throttles... god damn what a trash idea somebody had decades ago.
Reminds me of a Greg Banish interview. Sounds smart for 99% percent of it, then defends displacement on demand (his own pet project at some point apparently) "if you don't keep varying the pedal, it's great; you're just a terrible driver" WTF, fuck you bud.