Evo Live Map 88590015 Download Ready
Thread Starter
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
For the programmers:
http://www.banks.myzen.co.uk/NewEvoL...0015Source.zip
Source for the latest PC logger/mapper I posted last night. Links also updated in post #1.
http://www.banks.myzen.co.uk/NewEvoL...0015Source.zip
Source for the latest PC logger/mapper I posted last night. Links also updated in post #1.
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
Thanks mrfred, very good news. I should have explained that you start and continue the logging during all the mapping. ...
Questions:
1. Can you confirm that the fuel and timing maps that were read back from RAM matched your ROM? I suggest because there is no error checking that the changes are always read after writing and you make a quick visual scan that the fuel and timing map changes have taken and that the values are all safe. I've never had an issue at all except for the PC app crashing which should be much less likely on the new version without the graphing.
2."RPMs took a dip, but the car kept running." Presumably this was because you made a big change to timing and the ECU had to adjust it back or work the ISCV? I just want to be sure there were no ill effects due to the process of writing and that they were due to the new timing! This could be confirmed by making adjustments to the RAM map whilst still running from ROM, then switching to map #1 and seeing the same RPM dip as before.
...
Questions:
1. Can you confirm that the fuel and timing maps that were read back from RAM matched your ROM? I suggest because there is no error checking that the changes are always read after writing and you make a quick visual scan that the fuel and timing map changes have taken and that the values are all safe. I've never had an issue at all except for the PC app crashing which should be much less likely on the new version without the graphing.
2."RPMs took a dip, but the car kept running." Presumably this was because you made a big change to timing and the ECU had to adjust it back or work the ISCV? I just want to be sure there were no ill effects due to the process of writing and that they were due to the new timing! This could be confirmed by making adjustments to the RAM map whilst still running from ROM, then switching to map #1 and seeing the same RPM dip as before.
...
The timing values read back from RAM looked correct, but I did not explicitly compare to the ROM tables. I am pretty familiar with the general appearance of the timing and fuel tables, so I'm very confident that the tables first read into RAM matched the ROM values.
The rpms would only take a dip when the timing algorithm was pointed to bad timing values (in the RAM table). ISCV was undoubtedly compensating and bringing the rpms back up. When I bumped up the stock timing from 5 -> 10 deg at idle, the engine rpms increased and then drifted back to the target idle value, again undoubtedly from the ISCV.
Thread Starter
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
I do not need any further testing on this patch. The only issue was a few bugs in the pc software which are fixed with the latest version I posted.
I will not be migrating this version to other ecus because I am moving it all to dma. I have it all working on my car. I need to add a timeout routine in the ecu in case the comms is interrupted during dma transfer. I know what I need to do for this.
The only other thing to decide which I raised in a recent tephra thread was how we would do the actual map switching to allow 1d and 2d maps in ram. I am thinking that it is best that we point the ecu to vectors we store in ram. These will point to the usual rom location of the maps or values or to anywhere else we want. We just need to add a routine to populate all these vectors from a rom copy when the ecu is reset or reflashed. Again I know how to do this.
So from here on it is a tidy up of loose ends and organisation as to how we want to arrange all the realtime maps. No technical challenges remain really.
I will not be migrating this version to other ecus because I am moving it all to dma. I have it all working on my car. I need to add a timeout routine in the ecu in case the comms is interrupted during dma transfer. I know what I need to do for this.
The only other thing to decide which I raised in a recent tephra thread was how we would do the actual map switching to allow 1d and 2d maps in ram. I am thinking that it is best that we point the ecu to vectors we store in ram. These will point to the usual rom location of the maps or values or to anywhere else we want. We just need to add a routine to populate all these vectors from a rom copy when the ecu is reset or reflashed. Again I know how to do this.
So from here on it is a tidy up of loose ends and organisation as to how we want to arrange all the realtime maps. No technical challenges remain really.
Evolving Member
Joined: Apr 2007
Posts: 195
Likes: 1
From: Slovakia
John - will you also post some guide how to patch a ROM in order to make the DMA and live tuning available for other ROMs?
the latest version of the PC application is the one in this thread in post #1?
the latest version of the PC application is the one in this thread in post #1?
Thread Starter
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
Yes I will once I finalise it.
The latest plan is that I will supply the code that hooks into three interrupts to run the DMA. I will post all the details when I've got it all together. I want to make two changes before then - 1. Reset the DMA operation if there is a MUT timeout. 2. Move the DMA setup code from the MUT routine to the serial receive interrupt - this will improve response times and also allow the code to be universal for all ECUs. I want to make it really easy to patch.
What I will end up producing is the PC stuff and the ECU patches to allow reading and writing of RAM areas in the ECU using DMA. Tephra seems to be happy to move his maps to RAM (fuel, timing, boost, and I'm sure MIVEC can be added) and will add a routine to his patches to copy ROM to RAM when the ECU is first powered up/reflashed. My stuff will then allow editing these.
I also need to look at the common register addresses between the SH7052 (7/8) and the SH7055 (9). If possible my DMA code will be common for all... we'll see what I can streamline. I have what I want to do pretty clear in my head now I've seen where Tephra is going with his stuff and I now know what I want to focus on as above.
The latest plan is that I will supply the code that hooks into three interrupts to run the DMA. I will post all the details when I've got it all together. I want to make two changes before then - 1. Reset the DMA operation if there is a MUT timeout. 2. Move the DMA setup code from the MUT routine to the serial receive interrupt - this will improve response times and also allow the code to be universal for all ECUs. I want to make it really easy to patch.
What I will end up producing is the PC stuff and the ECU patches to allow reading and writing of RAM areas in the ECU using DMA. Tephra seems to be happy to move his maps to RAM (fuel, timing, boost, and I'm sure MIVEC can be added) and will add a routine to his patches to copy ROM to RAM when the ECU is first powered up/reflashed. My stuff will then allow editing these.
I also need to look at the common register addresses between the SH7052 (7/8) and the SH7055 (9). If possible my DMA code will be common for all... we'll see what I can streamline. I have what I want to do pretty clear in my head now I've seen where Tephra is going with his stuff and I now know what I want to focus on as above.
Thread Starter
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
I have just confirmed from the hardware manuals that the hardware registers between all the Evo 7-9 ECUs are the same for:
DMA interrupts
DMA registers
Serial receive interrupt
Serial registers
Serial transmit end interrupt
All the above means that the same code should work on all ECUs as long as I can find a bit of ROM and RAM in them all that is always unused.
DMA interrupts
DMA registers
Serial receive interrupt
Serial registers
Serial transmit end interrupt
All the above means that the same code should work on all ECUs as long as I can find a bit of ROM and RAM in them all that is always unused.
Evolved Member
Joined: Aug 2007
Posts: 569
Likes: 1
From: UK
I have just confirmed from the hardware manuals that the hardware registers between all the Evo 7-9 ECUs are the same for:
DMA interrupts
DMA registers
Serial receive interrupt
Serial registers
Serial transmit end interrupt
All the above means that the same code should work on all ECUs as long as I can find a bit of ROM and RAM in them all that is always unused.
DMA interrupts
DMA registers
Serial receive interrupt
Serial registers
Serial transmit end interrupt
All the above means that the same code should work on all ECUs as long as I can find a bit of ROM and RAM in them all that is always unused.
