OBD2 LT1 XDF $EE EEX creation

[Terminal_Crazy]

Do the flash roms HAVE to be fully zero'd and 0xFF set first ?
I always thought it was a bit crap that you couldn't just flash individual cells & update them.

Mitch

[In-Tech]

Do the flash roms HAVE to be fully zero'd and 0xFF set first ?
I always thought it was a bit crap that you couldn't just flash individual cells & update them.

Mitch

The quick answer is no. You can clear, or set, even a bit of a byte. A little bit longer answer(see what I did there? ) is did you correct the checksum for the change you made and the CEL is flashing rapidly cuz it is very unhappy The software could do a compare of your old file vs new file and write just that. If much has changed, that would probably be futile, time wise. Shit, you could write an idling bootloader, disable the checksum, send executable packets and almost have real-time emulation. Ummmmm this IS freeware, right?

[Tom H]

The quick answer is no. You can clear, or set, even a bit of a byte. A little bit longer answer(see what I did there? ) is did you correct the checksum for the change you made and the CEL is flashing rapidly cuz it is very unhappy The software could do a compare of your old file vs new file and write just that. If much has changed, that would probably be futile, time wise. Shit, you could write an idling bootloader, disable the checksum, send executable packets and almost have real-time emulation. Ummmmm this IS freeware, right?

Hi Carl,

Thank you Carl, I missed a key bit of info. You can erase and erase verify a single loc. My bad.
-Tom

xxxxxxxxxxxxxxxxxIf you program locations that are not FF and 0s transition to 1s the cell is internally not correctly
xxxxxxxxxxxxxxxxxxprogrammed. This can result in heat sensitivity and worst case a bricking. Suggest we follow the data sheet,
xxxxxxxxxxxxxxxIf I understand what I am reading their caution is "CAUTION: The algorithm must be followed to ensure proper and reliable operation of the device."
xxxxxxxxxxxxxI have not tested this but: If a cell that is programmed 00 is written to FF and an erase verify command is run, I think you will find faults from time to time. The "margin threshold" won't be met.



Can you suggest where I can find programming directions that indicate programming 0 --> 1 is OK?

-Tom

[Terminal_Crazy]

The quick answer is no. You can clear, or set, even a bit of a byte. A little bit longer answer(see what I did there? ) is did you correct the checksum for the change you made and the CEL is flashing rapidly cuz it is very unhappy

Yeah but you could recalc the checksum & update that byte.

The software could do a compare of your old file vs new file and write just that. If much has changed, that would probably be futile, time wise.

Steveo's EEHack does to a small extent

Shit, you could write an idling bootloader, disable the checksum, send executable packets and almost have real-time emulation. Ummmmm this IS freeware, right?

Great, will that be ready by tea time? :-)

I wish I knew more about these sytems, so I appologise if I throw in some random comments

There are a few of us who do follow these discussions even if we're sat here with a dumb expression on our face sometimes.
If the processors were ARM based, i'd be able to follow some of the dissassembly better.


Mitch

[Tom H]

Yeah but you could recalc the checksum & update that byte.
Mitch

If you need to fix a checksum, just program an un-used $FF location anywhere within the checksum range such that the sum is fixed. Harder if it is 16bit, you then need to mess with 256 locations. Still, up high there are largeish blocks of blank.

-Tom

[Tom H]

Hi,
I have completed my look through the '96-7 Tside FLASH programming code & commented the operation. The comments are best efforts only, I hope they are of use to you.

Big thanks to kur4o for his help with the tricky bits.

-Tom

[Tom H]

Hi,
I have completed my look through the '96-7 Eside FLASH programming code & commented the operation. The comments are best efforts only, I hope they are of use to you. It is interesting to look at the Programming Exec which has a mode (upload $35) that is new to me. I am thinking to write code for the upload section, but first I am planning to test my theory on an easy way to unbrick.

I am posting the Tside again, this time with a correction where code was cut out.


-Tom

[kur4o]

Nice work on the comments, much better to understand and complete.

Mode 35 is a built in mode for reading bin over odb2 port. Some of the earlier obd2 pcms have that built in the code, but later it got removed.

[Tom H]

Do the flash roms HAVE to be fully zero'd and 0xFF set first ?
I always thought it was a bit crap that you couldn't just flash individual cells & update them.

Mitch

Hi Mitch,

I have not gone through the AMD datasheet, but the Intel part requires a full erase. If a cell is FF, you can program it. Programming only takes 1s and makes 0s. If you program a location that is already programmed the result is not detailed in the datasheet but I would expect an AND function. The erase command does indeed program every bit in the array to zero before erase. This is done to make the threshold the same for all cells. When you do the verify commands an offset threshold is used to make sure the stored charge is enough for the life of the part. To be safe, erase as a whole and program locations that are FF only. The exception to the second part is what is done to erase.

It is my guess that the ECMs were programmed with all the code when the parts were soldered to the board and that calibration was added later perhaps on the assembly line. If you want to overwrite the calibration a full erase then program cycle is needed. It would be interesting if there are some folks who worked for GM at the time we could talk to.

-Tom