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.
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.
i'd prefer a seperate patch, just let me know what needs to be changed
For mode 02 change byte_1824C to $41 (default is $80)
For mode 03 change byte_18256 to $11 (default is $80)
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.
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!
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.
Last edited by steveo; 11-18-2015 at 09:51 PM.
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!
Good work!
1973 K-5 Blazer, TBI 350, TH400, 1 ton axles & 38" SSRs'
1975 280Z, TBI 350, 700R4
1953 M-38A1, TBI Buick 231
1951 Ford Panel, 5.3 with 4L80E
Bookmarks