Thread: Reverse engineering the Td5 ECU

No transformer ecu's I'm afraid.

If anything I'd be looking at modding the obd-ii code to make more engine parameters available as PID's. But that will require a lot more investigation before I know if it's feasible.

Those were the days Z80, 6800, 6802, 68000. My brain still hurts.

I love your work.

Originally Posted by OffTrack

No transformer ecu's I'm afraid.

Bugger.
"Discovery! Roll out!"
*handbrake fails, Discovery rolls down hill ploughing into toyota*
"Close enough"

I've had a few "Ah ha!" moments over the past couple of days.

The main one was that the software I'm using is very good at leading you up the garden path. What I've found is that the program is incorrectly displaying some instructions.

What is being shown is:

Code:

lea ($05B4.W), A0

which means "load the contents of memory location $05B4 into register A0"
instead of

Code:

lea $05B4.W, A0

which means "load the address $05B4 into register A0"

That is a pretty big difference, and once you ignore the brackets the instruction sequences start to make sense. Once I worked out what was going on I was able to find how the the ADC module processing queues were being allocated to CPU pins which I'd been unable to find previously.

What I'm finding is that the configuration is done in what appears to be a very convoluted way, but really makes sense if you look at it coming from the perspective of those who wrote the software.

The firmware has three distinct sections. The base "supervisor" code which is not altered by remapping. This contains the initial CPU configuration code, memory integrity checks, and checks that variant and fuel maps match, plus a small number of functions that are common to all variants. The once the setup is done the base code reads some configuration information from the variant map and jumps to the variant map code.

The variant map contains the vast majority of the code to manage the engine but the much of the information required to configure the CPU modules is contained in the first section of the fuel map. This might explain why map uploads failing during the initial stages of the fuel map upload were bricking the ECU so effectively.

From the perspective of maintaining maps, this arrangement means you can make alterations to the configuration by modifying the fuel map (bearing in mind I'm talking about how the ECU operates rather than adjusting fuelling tables), rather than changing the variant map code. I've come across routines that have a check which basically says "if the value at this location in the fuel map is zero we don't need to run this code". I need to do much more work on this but it seems that diagnostic tools are reading (directly or indirectly) these bits of information to give the listing of enabled ECU functions.

The other thing I've found is that quite a lot of code is run from interrupts, which is what you'd expect really. Certain modules will send an alert to the CPU when a process has been completed, for example when data has been received on a communications port. These alerts cause the CPU to "interrupt" what it was doing and run the code required to service the interrupt request. The first block of information in both the supervisor code and the variant map contain a table of addresses which correspond to the particular interrupt.

cheers
Paul

I too are a trodgolite when it comes to these matters.
Your work makes interesting reading,keep us informed.
Andrew

I'm both amazed and bamboozled. You MUST be a wizard.
Don.

Originally Posted by nod 130

I'm both amazed and bamboozled. You MUST be a wizard.
Don.

Unfortunately not, I'm just very persistent

I should add that the "trick" to getting started is to find the location of the reset vector in the firmware. Out of reset the M68336 reads from an external chip selected by CSBOOT and with a base address of 0x000000. The documentation will tell you where to find the reset vectors.

What you are looking for is the initial program counter. This tells the ECU address to begin executing the firmware.


For the NNN ECU this is address highlighted in green - vector number 1 at 0x004. This tells you the start point of the code is at address 0x418, so you can begin disassembly from that point.



cheers
Paul