Notices
ECU Flash

Realtime mapping update - exciting idea from Merchgod on Romraider we could use!

Thread Tools
 
Search this Thread
 
Old Feb 16, 2008 | 01:30 PM
  #1  
jcsbanks's Avatar
Thread Starter
Evolved Member
 
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
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.
Reply
Old Feb 16, 2008 | 04:10 PM
  #2  
codgi's Avatar
Evolved Member
Photogenic
Liked
Loved
Community Favorite
iTrader: (22)
 
Joined: Aug 2004
Posts: 2,493
Likes: 41
From: Atlanta, GA
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...
Reply
Old Feb 17, 2008 | 03:01 AM
  #3  
jcsbanks's Avatar
Thread Starter
Evolved Member
 
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
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.
Reply
Old Feb 17, 2008 | 06:33 AM
  #4  
MR Turco's Avatar
EvoM Staff Alumni
iTrader: (16)
 
Joined: May 2007
Posts: 3,233
Likes: 3
From: Massachusetts
This sounds great! Might as well avoid reinventing the wheel.
Reply
Old Feb 17, 2008 | 08:08 AM
  #5  
chrisw's Avatar
Evolved Member
iTrader: (2)
 
Joined: Mar 2003
Posts: 2,217
Likes: 0
From: Santa Cruz
Originally Posted by MR Turco
This sounds great! Might as well avoid reinventing the wheel.

in software development, you can never reinvent the wheel too many times.

Sounds like a great project!

look forward to seeing some results
Reply
Old Feb 18, 2008 | 11:07 AM
  #6  
evo828's Avatar
Evolving Member
 
Joined: Apr 2007
Posts: 195
Likes: 1
From: Slovakia


Can't wait until that goes public - hopefully I will be able to patch into my 96530006.
Reply
Old Feb 18, 2008 | 11:17 AM
  #7  
MR Turco's Avatar
EvoM Staff Alumni
iTrader: (16)
 
Joined: May 2007
Posts: 3,233
Likes: 3
From: Massachusetts
Originally Posted by chrisw
in software development, you can never reinvent the wheel too many times.

Sounds like a great project!

look forward to seeing some results
It's one thing to optimize the wheel it is another to try to build one from scratch.
Reply
Old Feb 18, 2008 | 01:33 PM
  #8  
jcsbanks's Avatar
Thread Starter
Evolved Member
 
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
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.
Reply
Old Feb 18, 2008 | 03:02 PM
  #9  
bnice01's Avatar
Evolved Member
iTrader: (4)
 
Joined: May 2007
Posts: 688
Likes: 0
From: Hurlburt Field, FL
good stuff cant wait
Reply
Old Feb 18, 2008 | 03:05 PM
  #10  
tephra's Avatar
EvoM Guru
15 Year Member
iTrader: (6)
 
Joined: Feb 2007
Posts: 9,486
Likes: 67
From: Melbourne, Australia
this sounds good, maybe the functionality could even be built into ecuflash?
Reply
Old Feb 18, 2008 | 06:51 PM
  #11  
MR Turco's Avatar
EvoM Staff Alumni
iTrader: (16)
 
Joined: May 2007
Posts: 3,233
Likes: 3
From: Massachusetts
Originally Posted by jcsbanks
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.
Reply
Old Feb 19, 2008 | 07:01 PM
  #12  
codgi's Avatar
Evolved Member
Photogenic
Liked
Loved
Community Favorite
iTrader: (22)
 
Joined: Aug 2004
Posts: 2,493
Likes: 41
From: Atlanta, GA
Originally Posted by jcsbanks
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.
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.
Reply
Old Feb 20, 2008 | 12:54 AM
  #13  
jcsbanks's Avatar
Thread Starter
Evolved Member
 
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
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.
Reply
Old Feb 20, 2008 | 05:54 AM
  #14  
jcsbanks's Avatar
Thread Starter
Evolved Member
 
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
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.

Last edited by jcsbanks; Feb 20, 2008 at 06:02 AM.
Reply
Old Feb 20, 2008 | 06:21 AM
  #15  
Oracle1's Avatar
Evolving Member
iTrader: (1)
 
Joined: Nov 2005
Posts: 425
Likes: 0
Well done John. Coming along nicely.

SK
Reply



All times are GMT -7. The time now is 10:26 AM.