Quote Originally Posted by spfautsch View Post
Actually it wasn't off by 6, it was off by 8. Yours had 01 in the first byte which I assumed was the lsb. I'm still not sure what this signifies, but apparently the low 4 bits aren't stored in the triplet structure.

$b5fe: 00 00 01 1f ff 4d ff ff ff ff

I assumed this was to be decoded to 0x1f4d1 but I think it should have been decoded to 0x1f4d0.

It just so happened that mine is as such:

$b5fe: 00 00 01 2b ff 8d ff ff ff ff > 0x2b8d1 = 178385 which happened to be what it reads exactly

But the salvage unit that reads 2675 in-car has:

$b5fe: 00 00 00 00 a7 00 00 00 00 00 > 0x0a70 = 2672

There's another 3 miles stored on it somewhere. Yours has 8, mine 1. I just have to figure out what units they're storing it in because it's not entirely obvious.



I think you're incorrectly assuming there's any executable code stored in whatever eeprom(s) there are on this thing. I'd wager the title to my car the program code is all in the uveprom. I'm not in any hurry to desolder it and dump. But I will if there's absolutely no other way to confirm where the different memory regions are stored physically.



The ultimate goal would be to reprogram these completely with open source tools.
i believe both the eeprom and uv prom would be addressed memory so both should be fully visible in the dump we get via the aldl.

i cant believe gm would leave the memory dump enabled. it defies all logic.