NefMoto

Hello i am proudly release the first version of my MED9Toolchain, which is basically a framework for writing code patches for MED9:
https://github.com/EliasKotlyar/MED9Toolchain

It took me a bit to get there, but now i hope that it can teach someone else in this community, as User "Basano" did for me.

Most important section would be the FAQ, where the whole process is described:
https://github.com/EliasKotlyar/MED9Toolchain/blob/master/FAQ.md

Its basically a Framework for code-changes, and i am really wondering why such things were not released to the public in the past. It can be easily adapted to any other ECU, without rewriting much.


A small bonus Feature:
It includes a sample "patch" for "mapswitch using cruise control" (LDRXN Table only) into almost any MED9.1 binary. Its not intended to work properly, its more a "proof of concept".

PS: Feel free to add new signatures/patches as MR.

Hi Elias!

Seems to be a good concept!
going to give this a go!

Follow the dollars, and get ready for the flood of clueless "professionals" asking for handholding and stealing your work :)

This is great work, nicely done. Adding a little disassembler phase on the front can really help to find locations in more complex situations also, versus just matching "needle" bytes.

IMO this is a lot of code for something very simple.
I also don't think recompiling every time makes much sense, because the only thing that changes are addresses, and you already need to splice in the jumps.

I insert placeholders into patches and use programmatic asm to replace the address accesses, and then match the needles in binaries usually via just bytemasks...

with ghidra you can statically find out exact registers which are free at any point you want to hook in a patch, and compile your code to use those only
with MG1 getting updates every few weeks, registers keep moving around, so a precompiled patch which doesnt inspect used regs in a routine becomes redundant quite quickly

This is taken care of by using code that does not clobber registers and picking insertion points with knowledge of the EABI. Upper context is saved on call, lower context can be saved and restored manually.
Never an issue in TriCore.

PowerPC no problem either if using NXP toolset and checking some options so it does not trash the stack or registers in subroutines.

That's not always possible, especially when you cant use calls(where pointers for maps need modification for example). Using jumps and regs that are free in the present "stock" code context has least chances of disrupting stock ecu operation(using calls assumes that you have free CSA and also increases code size for simple patches where modifying lower context registers is required- for example pointers being passed to interpolation routines)

Good job elias!  Basano 2.0 in the making.

This example is always possible, because you can simply replace the call into the map read subroutine and do your work there.
Competely disagree.
Stack depth is not affected in any way by calling a different subroutine and then jumping to the routine that was originally going to be called after modifying the registers.
Modifying random registers by eyeballing them instead of making use of the EABI convention is the best way to mess things up.

For switching maps there is never any need to touch any registers. On Bosch this is done using the double pointer autosar functionality that is already in the ECU.
On conti the above approach works perfectly fine.

For older stuff, on PowerPC there is no issue with the stack depth.

Furthermore, if you need to insert shit into places where you do not want to use EABI, then a compiler is completely useless anyway because it's going to use registers according to the EABI.
You lose all the ability to write code in C. Or need crazy workarounds.

That's the whole point of using Ghidra to get free regs, no eyeballing involved.
Not all maps/vars are loaded using double pointer method to load addrs. In fact BMW uses direct addrs in most MG1 functionality
Also I was referring to MCU CSA, not the one maintained by EABI/OS.
You can even pass on available regs to C compiler and limit it to use only from a given list while maintaining EABI conventions

So does Ford.
But this does not change the fact that the easiest patch point is in 99% cases simply replacing the map lookup routine call and modifying the arguments to it.
No need to do anything with registers other than creating headers one single time, and the patch does not need to be recompiled for every ECU revision.
Only the ram cell and asw addresses updated, which can easily be done with an automatic assembly framework.

Hello together

Finally i got some time to tinker around again with the MED9.

Regarding the whole "compile every time vs precompile once" topic:
I think it depends on the goals of the project and there is no "all fit all" solution. There are arguments on each side.


@R32Dude and @d3irb: Many thanks for your comments, it warms my heart that people appriciate my work.
@prj: Thanks for pushing me into the right direction. I appreciate your comments and your denial of "half backed" solutions.

I have commited a new "patch" which adds my personal holy grail: 0x23(readMemoryByAddress) and 0x3D(writeMemoryByAddress) KWP-Services. With them development becomes fairly easy in comparison to before. You dont need to wait until you can test some code, as you can instantly patch it into RAM and run it directly without having to "flash" it to the ECU.

For the calibration folks, i have some news. If someone would write some "double pointer-patches" for various maps, it should be possible to "livetune" the ECU with the help of the services mentioned above.

A bird told me that following maps are sufficient for tuning the ECU:
LDRXN
LDRXNZK
KFZW
KFZW2
KFPED
KRKATE
KFLDRL

Writing such patch should be really straight forward, but might be time consuming:
1. Find all places where the address of a map is used
2. Patch all places to use a pointer which will be located in ram
3. Set the real map address to the pointer on startup of the ECU
As soon the patch is done, you can write your own map into ram and then "redirect" the pointer to its address.

Choice of maps is very strange, seems like you do not have experience with calibration (or whoever suggested those).
The real solution is very different.

MED9 ECU's have CCP, which has predictable response times and built in download/upload commands.

To implement live tuning on this ECU you need to hook into output and modify the end parameters.
E.g. wgdc, camshaft setpoint, ignition setpoint, fuel correction, maf correction.
Then build it over a CCP bridge (probably have to change the CCP CAN ID's to something the gateway likes) and implement a real time measurement protocol and 2D maps for the corrections.
Essentially allowing to define an overlay or bypass map on the PC that the ECU is reading in real time instead of what is in the ECU.

But honestly, I don't see much point in it. Nr1 priority should be modifying the bootloader to flash the cal only. Then you can flash the ECU in under 60 seconds, so all the live tuning stuff becomes pretty unimportant.

How to achieve that?

By modifying the ECU to allow it to boot when the full checksum is not correct and some other conditions in the CBOOT.
And also writing a custom flash tool.

I assume still not available( to expensive) for hobby use?

It is not available at all on the market. No tool offers it.

You can't buy this. Make it yourself or continue dreaming.

You are talking about flash tool or mod that needs to be done on ECU? Or both?

Both need to be done. The ECU bootloader does not support flashing cal only out of the box.
And because of that no commercial flash tool exists that will flash cal only.

Hello together.

I have following idea in mind, as reverse-engeneering the Bootloader will be too much effort(for now):
1. MED9.1 is basically a MPC562 with attached M58BW016DB NOR Flash
2. Goal is to make that flash writable.
3. There is a Application Note which mentions some library code, which allows Flash R/W with a MPC555 with M58BF008. See attached PDF
4. Both Flash and Microcontroller mentioned in the App-Note are nearly same, so i would expect that this library will work.
5. I have already a Custom-KWP-Service and a C-Compiler ready to use.

I would implement a custom KWP-Service, which would expect a memory address and size. Then it would read the ram from this location and write it to flash using the library code above.
Filling the ram is already possible with the "writeMemoryByAddress" KWP-Service.

Unfortunately i cannot find the "STMICROELECTRONICS SOFTWARE DRIVERS" which are mentioned in the appnote yet. However it should be possible to obtain them from somewhere.
I know there are some limitations like interrupts/watchdog etc, but i can disable them before writing the flash.  Also my code can run from RAM to avoid any collisions.

@prj: What do you think about following "implementation" idea?

You can not execute from the flash while writing to it... I am sure I told you that already.

Yes you did, however i dont need to execute from flash anymore.

As i mentioned before, i have developed custom KWP services. I can R/W RAM and i can also execute from RAM. So idea would be:
1. Compile my "Flash-Writer-Code" into a binary blob.
2. Write that blob into ram using writeMemoryByAddress
3. Use my custom KWP-Service to execute that code in RAM
4. Code will then perform some changes on the flash and then reboot the system.

I know that the code needs to follow certain rules to be executed correctly in RAM(jump addresses etc).

There is already a bootloader doing this exact thing.
You are reinventing the wheel.

Also, after you do this, the ECU won't boot up because the checksums won't match.
To fix the sums you need to erase a lot more, defeating the purpose.

Hence you need to reverse the thing anyway.