Has it happend yet?
Thread Starter
Evolving Member
Joined: Sep 2006
Posts: 368
Likes: 0
From: California
Has it happend yet?
Has anybody corrupted or know anybody that has corrupted their ECU from overflashing?
Thats *Overflashing* not cutting out power mid flash or anything else. Just the simple factor of flashing one section so much that its reached its limit and went corrupt?
I'm sure a lot of us on here have changed our top end timing over 100 times in the last year or so. I know i have.
Thats *Overflashing* not cutting out power mid flash or anything else. Just the simple factor of flashing one section so much that its reached its limit and went corrupt?
I'm sure a lot of us on here have changed our top end timing over 100 times in the last year or so. I know i have.
10,000 flashes shouldn't be a problem for modern flash memory. A lot of the newer stuff is specified at 10,000 minimum and 100,000 nominal. There are outliers on either side, but I won't ever worry about overflashing my ECU.
Trending Topics
FWIW there will be a point in the near future where we will be able to alter values in the ECU ram through software, which means tuning the car and updating values, without reflashing the ECU until you have a map that is complete..
It looks like this is very close, and requires only minimal mods to do it (and of course software capable of doing it) this has been discussed on my site during the disassembly of the rom, and one of the main contributors had mentioned a method of reading/writing the ram area using a modified mut request..
It looks like this is very close, and requires only minimal mods to do it (and of course software capable of doing it) this has been discussed on my site during the disassembly of the rom, and one of the main contributors had mentioned a method of reading/writing the ram area using a modified mut request..
Did this ever happen?
A little OT, but this is some interesting stuff I ran across...
http://www.renesas.com/fmwk.jsp?cnt=...2r_ecu_series/
I think that may be who makes our ECUs. Anybody have an ECU lying around and can check the part number on the microcontroller?
Last edited by GTLocke13; Dec 4, 2007 at 11:43 AM.
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
I have live editing of the high octane fuel and timing maps (copied to ECU RAM) on my ECU.
Trouble is, it can't be rolled out to all ECU versions without a rewrite of the PC side loggers to allow them to display and edit the live maps which are in different locations and dimensions in each ECU!
Trouble is, it can't be rolled out to all ECU versions without a rewrite of the PC side loggers to allow them to display and edit the live maps which are in different locations and dimensions in each ECU!
I have live editing of the high octane fuel and timing maps (copied to ECU RAM) on my ECU.
Trouble is, it can't be rolled out to all ECU versions without a rewrite of the PC side loggers to allow them to display and edit the live maps which are in different locations and dimensions in each ECU!
Trouble is, it can't be rolled out to all ECU versions without a rewrite of the PC side loggers to allow them to display and edit the live maps which are in different locations and dimensions in each ECU!
I have live editing of the high octane fuel and timing maps (copied to ECU RAM) on my ECU.
Trouble is, it can't be rolled out to all ECU versions without a rewrite of the PC side loggers to allow them to display and edit the live maps which are in different locations and dimensions in each ECU!
Trouble is, it can't be rolled out to all ECU versions without a rewrite of the PC side loggers to allow them to display and edit the live maps which are in different locations and dimensions in each ECU!
I have live editing of the high octane fuel and timing maps (copied to ECU RAM) on my ECU.
Trouble is, it can't be rolled out to all ECU versions without a rewrite of the PC side loggers to allow them to display and edit the live maps which are in different locations and dimensions in each ECU!
Trouble is, it can't be rolled out to all ECU versions without a rewrite of the PC side loggers to allow them to display and edit the live maps which are in different locations and dimensions in each ECU!
Last edited by GTLocke13; Dec 4, 2007 at 11:42 AM.
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
PROGRESS SO FAR
ECU:
Modified the MUT routines so that I can read and write RAM (difficult, but done)
Found space in RAM for the fuel and timing maps (easy, done)
Leave the pointers for map set 0 pointing to the ROM maps, change the pointers for map set 1 to point to the RAM maps (easy, done)
Stop the ECU continually resetting the selected map set to 0 (difficult, but done)
Use a MUT request attached to new code to copy the ROM maps to RAM (medium difficulty, done)
Stop the ECU allowing map set 1 to be selected unless valid header information is present in RAM - so it prevents selecting RAM that may be full of junk after ECU reflash or power down (difficult, but done)
PC:
Learn visual basic (medium, but time consuming, done on a beach in Sri Lanka
)
Borrow Mitsubishi logger source from Jack (many thanks!)
Add buttons with sequences of request IDs to allow copying of maps, selecting map set 0 or 1 (easy, but hard coded so has to be different for each ECU)
Learn how to use grids and datasets (medium, but time consuming)
Display a grid of the fuel map with the RPM and load values hard coded (easy)
Program a button to read the RAM map from the ECU and display (easy, but hard coded for each ECU)
Grid is editable (easy)
Program a button to write the grid back to RAM in the ECU (easy)
SUMMARY:
The ECU side is technically more difficult, but was easier for me than the PC side since I found SH2 assembly easier than Visual Basic!! The stuff done on one ECU is now relatively easily transferred to other ECUs.
The development challenge is making the PC side work for the whole range of ECUs in some intelligent/configurable way. I've done it with hard coded shortcuts so far.
I wondered about starting an open source project for a standalone PC program in Visual Basic that accesses the Tactrix virtual serial port to allow map editing.
Evoscan isn't open source. Mitsubishilogger isn't either, and Jack is delayed on developing it further. If we could truly open up the PC side with a really simple app to allow just map editing it might fly?
ECU:
Modified the MUT routines so that I can read and write RAM (difficult, but done)
Found space in RAM for the fuel and timing maps (easy, done)
Leave the pointers for map set 0 pointing to the ROM maps, change the pointers for map set 1 to point to the RAM maps (easy, done)
Stop the ECU continually resetting the selected map set to 0 (difficult, but done)
Use a MUT request attached to new code to copy the ROM maps to RAM (medium difficulty, done)
Stop the ECU allowing map set 1 to be selected unless valid header information is present in RAM - so it prevents selecting RAM that may be full of junk after ECU reflash or power down (difficult, but done)
PC:
Learn visual basic (medium, but time consuming, done on a beach in Sri Lanka
)Borrow Mitsubishi logger source from Jack (many thanks!)
Add buttons with sequences of request IDs to allow copying of maps, selecting map set 0 or 1 (easy, but hard coded so has to be different for each ECU)
Learn how to use grids and datasets (medium, but time consuming)
Display a grid of the fuel map with the RPM and load values hard coded (easy)
Program a button to read the RAM map from the ECU and display (easy, but hard coded for each ECU)
Grid is editable (easy)
Program a button to write the grid back to RAM in the ECU (easy)
SUMMARY:
The ECU side is technically more difficult, but was easier for me than the PC side since I found SH2 assembly easier than Visual Basic!! The stuff done on one ECU is now relatively easily transferred to other ECUs.
The development challenge is making the PC side work for the whole range of ECUs in some intelligent/configurable way. I've done it with hard coded shortcuts so far.
I wondered about starting an open source project for a standalone PC program in Visual Basic that accesses the Tactrix virtual serial port to allow map editing.
Evoscan isn't open source. Mitsubishilogger isn't either, and Jack is delayed on developing it further. If we could truly open up the PC side with a really simple app to allow just map editing it might fly?
PROGRESS SO FAR
ECU:
Modified the MUT routines so that I can read and write RAM (difficult, but done)
Found space in RAM for the fuel and timing maps (easy, done)
Leave the pointers for map set 0 pointing to the ROM maps, change the pointers for map set 1 to point to the RAM maps (easy, done)
Stop the ECU continually resetting the selected map set to 0 (difficult, but done)
Use a MUT request attached to new code to copy the ROM maps to RAM (medium difficulty, done)
Stop the ECU allowing map set 1 to be selected unless valid header information is present in RAM - so it prevents selecting RAM that may be full of junk after ECU reflash or power down (difficult, but done)
PC:
Learn visual basic (medium, but time consuming, done on a beach in Sri Lanka )
Borrow Mitsubishi logger source from Jack (many thanks!)
Add buttons with sequences of request IDs to allow copying of maps, selecting map set 0 or 1 (easy, but hard coded so has to be different for each ECU)
Learn how to use grids and datasets (medium, but time consuming)
Display a grid of the fuel map with the RPM and load values hard coded (easy)
Program a button to read the RAM map from the ECU and display (easy, but hard coded for each ECU)
Grid is editable (easy)
Program a button to write the grid back to RAM in the ECU (easy)
SUMMARY:
The ECU side is technically more difficult, but was easier for me than the PC side since I found SH2 assembly easier than Visual Basic!! The stuff done on one ECU is now relatively easily transferred to other ECUs.
The development challenge is making the PC side work for the whole range of ECUs in some intelligent/configurable way. I've done it with hard coded shortcuts so far.
I wondered about starting an open source project for a standalone PC program in Visual Basic that accesses the Tactrix virtual serial port to allow map editing.
Evoscan isn't open source. Mitsubishilogger isn't either, and Jack is delayed on developing it further. If we could truly open up the PC side with a really simple app to allow just map editing it might fly?
ECU:
Modified the MUT routines so that I can read and write RAM (difficult, but done)
Found space in RAM for the fuel and timing maps (easy, done)
Leave the pointers for map set 0 pointing to the ROM maps, change the pointers for map set 1 to point to the RAM maps (easy, done)
Stop the ECU continually resetting the selected map set to 0 (difficult, but done)
Use a MUT request attached to new code to copy the ROM maps to RAM (medium difficulty, done)
Stop the ECU allowing map set 1 to be selected unless valid header information is present in RAM - so it prevents selecting RAM that may be full of junk after ECU reflash or power down (difficult, but done)
PC:
Learn visual basic (medium, but time consuming, done on a beach in Sri Lanka
)Borrow Mitsubishi logger source from Jack (many thanks!)
Add buttons with sequences of request IDs to allow copying of maps, selecting map set 0 or 1 (easy, but hard coded so has to be different for each ECU)
Learn how to use grids and datasets (medium, but time consuming)
Display a grid of the fuel map with the RPM and load values hard coded (easy)
Program a button to read the RAM map from the ECU and display (easy, but hard coded for each ECU)
Grid is editable (easy)
Program a button to write the grid back to RAM in the ECU (easy)
SUMMARY:
The ECU side is technically more difficult, but was easier for me than the PC side since I found SH2 assembly easier than Visual Basic!! The stuff done on one ECU is now relatively easily transferred to other ECUs.
The development challenge is making the PC side work for the whole range of ECUs in some intelligent/configurable way. I've done it with hard coded shortcuts so far.
I wondered about starting an open source project for a standalone PC program in Visual Basic that accesses the Tactrix virtual serial port to allow map editing.
Evoscan isn't open source. Mitsubishilogger isn't either, and Jack is delayed on developing it further. If we could truly open up the PC side with a really simple app to allow just map editing it might fly?
Plus - it can get a little dangerous when you are reflashing your ECU while rolling down the highway with the car turned off.
If you wanted to do an open source standalone tuning app I'm guessing you couldn't use the mitsulogger interface code and would have to start over from scratch. Unless you could convince Jack to allow you to distribute that part of the source code.
When you say "each ECU" do you mean every individual ECU or each of the several different ROM codes out there? If it has to do with different ROM codes you handle it like ECUFlash does and use a definition file.
Speaking of which, what Renesas CPUs are in the Evo? I found a boatload of data sheets and manuals and wanted to start looking at disassembly of the source code, but I don't know which series of chips they're using. Are there any free disassemblers out there so I don't have to write my own? And has anyone posted the assembly code with notes as to what's been figured out and what hasn't?
Is anyone looking at disassembling the ACD controller on the IX?
When you say "each ECU" do you mean every individual ECU or each of the several different ROM codes out there? If it has to do with different ROM codes you handle it like ECUFlash does and use a definition file.
Speaking of which, what Renesas CPUs are in the Evo? I found a boatload of data sheets and manuals and wanted to start looking at disassembly of the source code, but I don't know which series of chips they're using. Are there any free disassemblers out there so I don't have to write my own? And has anyone posted the assembly code with notes as to what's been figured out and what hasn't?
Is anyone looking at disassembling the ACD controller on the IX?