Here's current progress on eeprom mapping. Some items are fairly easily confirmed, some a developed theory, and some just a wild-assed-guess. The number of question marks added after the info is relative to my confidence.
Code:
$b600: 01 2b ff 8d ff ff ff ff 00 00 00 00 00 00 00 00 00 00 = odometer minus low 4 bits = 0x2B8D0 178384 mi
$b612: 01 2b ff 8d ff ff ff ff 00 00 00 00 00 00 00 00 00 00
$b624: 01 2b ff 8d ff ff ff ff 00 00 00 00 00 00 00 00 00 00
$b636: 00 (33 bytes)
$b657: 05 = vss counter * 1k = 1.25 mi ?
$b658: 00 (21 bytes)
$b66d: 01 31 ff d6 ff ff ff ff ff ff ff ff ff ff ff ff ff ff = erase counter ??
$b67f: 4a 9f
$b681: 44 dc = olm remaining engine revolutions ??
$b683: 02 d6 37 48 2d 5b 34 c7 04 67 36 1e 17 91 49 46 31 01 1d a1 48 2e 40 5e 39 18 35 af 12 (dtc history ???????)
$b6a0: 13 04 = olm remaining miles ??
$b6a2: 0f aa 55 = vats resistor code (15) (aa 55 = tolerance ???)
$b6a5: 01 (32 bytes)
$b6c5: ff 3a
$b6c7: 02 manual trans ??
$b6c8: 00 00
$b6ca: fe = mode5 lockout
$66cb: 40 00 10 00 00 00 80 00 20 00 08 01 80 40 20 10 08 04 02 80 00 08 04 02 01 00 00 00 00 20 00 80 00 (33 bytes ff in 94 eeprom - poss. custom PCM polling msg ?????)
$b6ec: ff (259 bytes) unused
$b7ef: <vin> (17 bytes)
If anyone spots missing bytes or overlapping addresses please point it out and I'll clean it up. The hex editor I use doesn't support copying the hex conversion so a lot of this was typed while tabbing between my notes and ghex.
The erase counter is just an educated guess - I've noticed it increment several times after starting the engine and letting it idle, and most recently after resetting the oil life monitor (olm).
The oil life monitor stuff seems pretty straightforward, but I'm somewhat confused as to why the two counters are stored so far apart, and what the jumble of info between them might be. As such I'm giving this one two question marks. Whatever the case, I've noticed the remaining revolutions decrement from dump to dump when the engine has been running. After I cleared the olm from the dic controls the revolution counter was reset to 20000 (0x4320 hex) and the miles to 5885 (0x16fd).
On the vats code, I've no idea what the following two bytes are - my guess is tolerance. But the key code is stored at $b6a2 in the clear based on having dumps from two with 15s and one with a 9. Also, per NomakeWan's previously posted info, when the eeprom is read without the correct vats resistor the 02 request returns 00 00 00 for these bytes. And there appears to be an authentication routine for this, it's not as simple as hooking up a trim pot and finding the resistance. It appears a specific sequence must be recognized - i.e. key-in pin goes low, vats read, ign1 and ign3 go high and key-in also goes high. Just a guess but I tried all 14 values about 3 different ways last night and was unable to read these bytes from the salvage ccm.
Since we have no dumps from ZR-1s and all we have appear to be equipped with the C68 climate control, that's about as far as I can go on vehicle options. I do have a message out to someone I know with a 90's ZR-1, but he may or may not be willing / able to help.
One other bit I've noticed but haven't found in my notes yet is that the alarm status (aka utd status) seems to be stored in eeprom as well. My assumption is if I arm the utd and then disconnect the battery that the doors will lock when I hook it back up.
Plans are to try tickling the vss input with a tone generator today to see if the vss counter at $7057 / $6b57 increments. After that I might do something completely idiotic and try to zero the odometer triplet and erase the mode5 lockout bit / byte (on the salvage ccm).
steveo I notice an oddity when trying to read only the eeprom range with flashack. If I specify module f1 with offset b600 and 200 bytes (all hex) it complains.
Code:
ERROR! Some parameters are nonsensical. Please check your settings in the advanced tab.
Not a show stopper but would save me a bunch of time dumping memory.
Bookmarks