Realtime mapping update - exciting idea from Merchgod on Romraider we could use!
Realtime mapping update - exciting idea from Merchgod on Romraider we could use!
1. Based on an idea Merchgod posted on Romraider (prev Enginuity), we could use Ecuflash to edit our realtime maps by making the changes and then saving them quickly with ctrl-s. My PC application would be open at the same time and when the write button was clicked it would read the latest ROM file that was just saved by Ecuflash and then extract the 1k (2k on Evo IX for more maps) part that had all our realtime maps bunched together and send it to the ECU's RAM for realtime maps in about half a second using DMA. Only change to Ecuflash is in the xml definition to have the new memory locations for the ROM copies of realtime maps. The PC app would be greatly simplified! To permanently write the changes you've tested in RAM, you'd simply write the latest ROM image to the ECU using Ecuflash.
2. The PC app and the ECU would both calculate a checksum for the RAM blocks and they would be displayed/compared in my PC app after each write.
3. I still need to add some code to the ECU DMA routines to handle timeout. I also need to tidy up the DMA code to make it slick to transfer to multiple ECUs.
2. The PC app and the ECU would both calculate a checksum for the RAM blocks and they would be displayed/compared in my PC app after each write.
3. I still need to add some code to the ECU DMA routines to handle timeout. I also need to tidy up the DMA code to make it slick to transfer to multiple ECUs.
To make it cleaner what you should do is actually just diff the one from the ECU with the changed one on the PC and only write the diff. But maybe that is already done elsewhere...
Then I'll be writing potentially lots of little blocks and I'd need a lot more code to process it all. I can't be bothered 
The write all method seems to work well with standalones that communicate at similar baud rates.

The write all method seems to work well with standalones that communicate at similar baud rates.
Trending Topics
I was going to do a load on it tonight, but I ended up spending a load of time fixing my HKS hard pipe kit (comes on the FQ models) that decided to pop a hose when I was under boost, and it took a few removals/test drives/refits before I stopped it sounding like an oboe whenever it had more than 1.2 bar. Now all fixed.
This week I plan to get the timeout stuff working so that if there is a comms fault the ECU exits the DMA stuff gracefully. Presently I find it works robustly, but doesn't like it if I do silly things like turn off the ignition or pull a cable whilst DMA is in progress.
This week I plan to get the timeout stuff working so that if there is a comms fault the ECU exits the DMA stuff gracefully. Presently I find it works robustly, but doesn't like it if I do silly things like turn off the ignition or pull a cable whilst DMA is in progress.
Dont worry, i dont think ecuflash likes it if that happens either. As long as it doesnt brick the ecu i am sure people will be happy.
I believe ECUFlash does a similiar check. In general there's probably a bunch of stuff from that, that could be reused if it was ever openly shared.
It loads a kernel into RAM and does a CRC32 on each flash block to see what needs to be changed. The minimum block size to flash is still much larger than what I want to put into RAM, and also CRC32 may not be ideal to do with the engine running. I think it is just too complex for a first go.
OK, I now have the timeout working properly on DMA, so you can unplug a cable or key off during DMA and whilst the DMA may be partially through a block at least the ECU can log again without having to pull the middle ECU plug to kill the power to hard reset it 
It is linked to the MUT timeout, so I have a routine that will add a few lines to Tephra's code that he runs off the main loop that checks to see if MUT is timed out - if it is it resets the DMA registers and my variables that control it. This was actually quite a headache to do and a bit of a boring thing to add, but the robustness is definitely worth it!
So now I start to tidy up the DMA code to make it as easy to transfer to lots of ECUs as possible, then I give it to Tephra/all with documentation, then I resume work on the PC stuff to write these blocks from an Ecuflash .hex file to RAM.
IF I can get the stuff out of the MUT routines and instead snoop for my E0,E1,E2 DMA trigger request IDs by hijacking the serial receive interrupt, then I think I could make a universal patch that will work for any ECU, perhaps with just a few routines moved for the SH7052 (7/8) and SH7055 (9), but the same code, same registers, same hooks etc. The PC app could also be universal for all ROMs. The custom stuff for each ECU type will be in moving some maps around and changing xml definitions for Ecuflash to show the RAM maps.

It is linked to the MUT timeout, so I have a routine that will add a few lines to Tephra's code that he runs off the main loop that checks to see if MUT is timed out - if it is it resets the DMA registers and my variables that control it. This was actually quite a headache to do and a bit of a boring thing to add, but the robustness is definitely worth it!
So now I start to tidy up the DMA code to make it as easy to transfer to lots of ECUs as possible, then I give it to Tephra/all with documentation, then I resume work on the PC stuff to write these blocks from an Ecuflash .hex file to RAM.
IF I can get the stuff out of the MUT routines and instead snoop for my E0,E1,E2 DMA trigger request IDs by hijacking the serial receive interrupt, then I think I could make a universal patch that will work for any ECU, perhaps with just a few routines moved for the SH7052 (7/8) and SH7055 (9), but the same code, same registers, same hooks etc. The PC app could also be universal for all ROMs. The custom stuff for each ECU type will be in moving some maps around and changing xml definitions for Ecuflash to show the RAM maps.
Last edited by jcsbanks; Feb 20, 2008 at 06:02 AM.







