$EE Flash tool progress

**kur4o** · 11-11-2015

I have a patch for eside for mode 02 and 03, tested and working. You can add it as mandatory for some extended parameters.
It is as simple as two bytes changed. I have it in the Eside ALDL patch included, but also can make a separate only 2 and 3.

**steveo** · 11-12-2015

i'd prefer a seperate patch, just let me know what needs to be changed

**kur4o** · 11-12-2015

For mode 02 change byte_1824C to $41 (default is $80)
For mode 03 change byte_18256 to $11 (default is $80)

**jthompson122183** · 11-13-2015

here is what is in the tunercats tdf editor for flash programming

Attachment 9785

**steveo** · 11-15-2015

here's my idea for the day.

im already planning on selective tside/eside flashes (if the user presents the 'old' bin for comparison, program only flashes eside/tside selectively).

half as much flashing is potentially twice as much safety, less wear and tear, and lots of saved time.

but i had one more idea

in an eeprom like this ecm has, erasing it effectively SETS all bits, right? and 'programming' it is the act of unsetting any bits that are zero?

so technically, if after erasing, the entire eeprom is 0xFF?

so i could map out areas of the bin that are continuous areas of 0xFF (there are quite a few) or areas which are known to be ignored/unused, and selectively not flash them?

**RobertISaar** · 11-16-2015

i don't see why not, but then you'll be stuck if you want to upload a patched BIN, or at least need to allow for changes to the flashed area.

if these PROMs supported selective erasure(I don't think they do), then you could have something like what most of the OBD2 programs do and only bother erasing and updating calibration blocks. safer too, since if there were an issue, code would still exist to allow for a flash without having to pull the PROMs.

**steveo** · 11-16-2015

yeah i think they're 'apply voltage and erase the whole thing' style eeproms.

i don't see why not, but then you'll be stuck if you want to upload a patched BIN, or at least need to allow for changes to the flashed area.

i was thinking probably skipping 'unused' areas is generally a bad idea, but the e-side has TONS of unused space, so i'll have an accelerated e-side flash routine that can be disabled for people that patch that side.

that's on top of checking each bin for sequences of 0xff and determine optimal spots to skip there

**steveo** · 11-16-2015

at the point where i'll need testers with socketed ecms (or spares), any takers please post or pm me

**lionelhutz** · 11-16-2015

I just looked at the datasheet for the AN28F512. You have to send the chip an erase command and that erases the whole chip. Then, you have to verify it's erased by using the erase verify command on each address. checking for FF. The datasheet says to attempt erasing up to 6000 times if you encounter a byte that isn't FF during the erase verify. Basically, if the 11th address fails to read FF then you hit it with another erase command and then start using the erase verify commands at the 11th address until you've read them all or you find another failure and then you erase again and keep going.

Then you have to use the write command and the write verify commands to write each byte, repeating the write command each type the write verify fails to return the correct data. The datasheet says to attempt programming each byte up to 25 times, but the first or second time usually verifies correctly.

**steveo** · 11-16-2015

sounds like what i read last night!

from the tool's perspective, once the code is run, it sends message 0x55 repeatedly (one would assume while erase is still not done), then sends 0xAA when finished.

i'm working on disassembling the GM erase routine right now to see what's done on the code level.

the amount of time seems to vary, probably while it's repeatedly erasing the chip and re-testing. i have figured out the structure of the code but not exactly what it's doing. i'll post a disassembly when it's ready.

understanding this routine is important, since the erase operation seems to be a common time for it to fail.

**kur4o** · 11-17-2015

In the disassembly there is alot of mystery aa and 55 bytes compare. Today I found in an eeprom soft that there is option to fill empty chip with 00(00000000) 55(01010101) aa(10101010) or ff(11111111). These are equally spaced, and I guess are state of the bits or maybe erase the bits in cross patern. Maybe these checks are to verify the chip got erased and written successfully. At least I have a starting point now.

**steveo** · 11-17-2015

big news! i ordered some sockets n chips off ebay for my spare ecm, so i decided to just bite the bullett and try the flash routine

and it kinda worked! it got all the way to 0xFFFF! .... but tried to write a few bytes out of bounds and failed due to a math error on my part

however i did learn three things..

1. it's almost perfect!
2. writing out of bounds does produce an error
3. my write failure mode worked perfectly! if it gets a series of write retry failures (which it did in this case), it assumes either a flash error or communication error, then jumps back to the main routine, tries to erase that chip again, and start over. since i knew it was done for anyway, i let it run for an hour and had no errors except that final write failure.

so i'm almost there!

**steveo** · 11-18-2015

so i redid it and bricked kur4o's ecm too

on reivew, it worked perfectly up until the last packet again (0xff80-0xffff), until an off-by-one error occurred in a check in the 'write' packet builder that i'd placed to prevent writing out of bounds. it returned an error and the last 0x80 bytes never got written.

im really sucking at off-by-one errors lately.

but i think i have it nailed now!

to make matters worse my 'retry' routine kicked in since it hit a fail condition, and constantly tried to re-erase that side and try again to get a successful completion. i do like that failure mode but as mentioned, i think it needs to give up after a few tries.. i'll build that into the logic somewhere.

**steveo** · 11-20-2015

kur4o tried again and it wrote the t-side image to both sides.

i found the problem; just an equals sign.

in c++, == compares two values, and = stores a value. i had stored 0xF4 when i meant to compare it and figure out which side to flash... derp!

i fixed that and gambled my car's ecm on it, and it worked!

also tried selective write (only eside and only tside) and it seemed to work well, which is great, because it cuts flashing time in half if you just tweak one table...

so, more testing required, but i think we're about one or two bugs away from a free (and awesome) flash tool for $EE!