Very impressive. I'm an old programmer (cobol, fortran c++) so seeing your work here I can appreciate the work you are putting in. Bloody impressive!
Printable View
Very impressive. I'm an old programmer (cobol, fortran c++) so seeing your work here I can appreciate the work you are putting in. Bloody impressive!
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.:cool:
Bugger.Quote:
Originally Posted by OffTrack
"Discovery! Roll out!"
*handbrake fails, Discovery rolls down hill ploughing into toyota*
"Close enough"
:p
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:
which means "load the contents of memory location $05B4 into register A0"Code:lea ($05B4.W), A0
instead of
which means "load the address $05B4 into register A0"Code:lea $05B4.W, 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.
Unfortunately not, I'm just very persistent ;)Quote:
Originally Posted by nod 130
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.
http://www.aulro.com/afvb/attachment...1&d=1369597938
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.
http://www.aulro.com/afvb/attachment...1&d=1369597956
cheers
Paul
I've found having a decent text covering the processor is a huge help. This book for instance gives very clear explanations of things that can be virtually impenetrable in the Motorola documentation.
https://www.aulro.com/afvb/images/im...013/05/164.jpg
This book by Thomas Harman often appears in the "further reading" list of articles on the MC683xx processors, and is well worth hunting down if you want to dig into CPU32 based systems. I got a slightly ratty copy on abebooks for around $18 delivered.
cheers
Paul