here is what is in the tunercats tdf editor for flash programming
Attachment 9785
here is what is in the tunercats tdf editor for flash programming
Attachment 9785
97z28 A4 obd1 swap(16188051)
Tunerpro Newbie
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?
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.
yeah i think they're 'apply voltage and erase the whole thing' style eeproms.
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.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.
that's on top of checking each bin for sequences of 0xff and determine optimal spots to skip there
at the point where i'll need testers with socketed ecms (or spares), any takers please post or pm me
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.
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.
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.
Bookmarks