If you would have read the thread they have designed the software to only write the blocks of data that you edit.

 

First of all, EcuTek does erase the whole flash, openECU software only erase flash blocks that has different data from ECU image. Most of all the calibration data is stored in flah block 2 and three, which are 4kbyes. So these blocks only takes 5 seconds to flash your ECU. And as for EcuTek, it takes up to 90 seconds to flash your ECU. Techtom on erase 5 blocks of flash memory which is 32K, and it takes forever as well.

 

i have read the whole thread since it was started on day 1. but nowhere does it explain how the rewrite is set up. i was asking if they knew if each little adjustment counted as 1 flash or does the whole thing have to be rewritten to count as a flash.

 

I am currently working on a data logger for the evo. Mitsubishi protocol is slower because it uses OBD II to get data values. But we have found a way to get data directly thru RAM, and bypassing OBD II. Thus making the protocol faster. This is the same way DeltaDash do for Subaru.

 

If you guys need address, I have disassemble the EVO 8 and 9 ROMS for 6 months now. I have found alot data values and maps. I've even found the Idle Stepper Lookup table, which is a 27 x 8 map. Also this new map has been tested and confirmed.

Also the OBD II stuff, just finding the code in memory such 0301 misfire # 1 cylinder, removing that code will not solve your check engine light. OBD II uses over 300 subroutines that constanly checks. By removing that code will just erase that code from being stored in a RAM location for the OBD II scan tool to pick up, but will not solve your check engine light or limp home mode. I am working with a friend in Japan on all the OBD II protocol for Mitsubishi ECU's.

 

Awesome

 

Flash is written in sectors, and the write limit is not based on the number of total flashes, but on the number of times you flash that sector.

Because ECUFlash writes only the regions you need, then you could get well over 100 writes if you didn't write to the same region each time. One product that I've worked with has an intelligent flash manager that modifies the flash region written to each time, so you "wear in" the flash equally over time.

But in case no one believes Al's 100 write limit quote, he is correct. I've looked at the SH7502 and it is 100. However, this is always a conservative number that the manufacturer can guarantee. After 100, you don't know if certain values in your map will fail to save properly or not.

Isn't it possible to set up the maps so that when we tune with the ECUFlash, new map values are read from / written to RAM? That way, you can write as much as you want, and only commit your changes to flash when you're happy.

 

That's great to hear. I know it's possible, one way or another, because I have used DSMLink in my Eclipse for years. I would be able to datalog and display 20+ values all sampling at over 20+/second, IIRC.

DSMLink used the stock DSM ECU that the DSMLink guys socket, write, and control with their own open-source code.

That's what DSMLink does. All of you fine-tuning is stored in RAM, but your base settings (or flash so to speak) are permanent. The only downside is that any RAM based settings would be lost when the battery was unhooked. But, this would eliminate the 100 flash limit.

Eric

 

thank you. all i wanted to know.

 

Yes we are currently working on that as well.

 

You seem to have all of the bases covered, Jason.

Can't wait to see the software release and continued updates from the community.

Eric

 

Awesome, you guys are geniuses. I take it you'll actually have to modify the ECU code to jump to a different base address, then?

 

Correct

 

This is all the good information I like to hear.. That is probably the biggest concern anyone who plans on doing tuning on a regular basis would have. So adjusting from RAM first to do the tunes, then writing perminently once, is alot safer and of course, likely the way the "professional products do it"

The logging is what has me most interested, the stepper motor and other idle control features, and perhaps adjustable thresholds for OBDII Triggers would also interest me more than the tuning maps (though scaling and base tuning is something I plan to do on my car anyway)

 

I'm interested in the logging part as well. My current solution (like some others) is to run ECU+ with 0% timing and fuel trims and have it do the datalogging. It would be neat to see how ECUFlash gets around the 10Hz limitation of OBD II. I imagine that they are using the SCI port on the 7502 to transmit the data, which would be an operation that's mutually exclusive from programming maps.