Reading eeprom from delco PCM, MC68336 based

[iblackford]

Well getting back to this I am finally getting some data from the eeprom, I haven't made a fancy GUI yet for it but I thought I would try to push ahead anyways and see if I run into further issues. Here's where I'm at:

-I completely rewired the PCM to my programmer. I confirmed all the address and datalines, and checked the control lines
-Device is setup in word mode using all 16 data lines.
-read a few blocks of data, it doesn't mean much to me yet.

0x04000 : DEBC 00 10 4A32 7431 00 12 01 EE1A 00 9AE C249 F25A 466F F67A 00 00 00 00 00 00 00 00 00 00 72F9 00 C59A 72F9 00 C5C2 72F9
0x04020 : 00 C5EE 72F9 00 251A 72F9 00 2552 72F9 00 258E 72F9 00 25CA 72F9 00 A56 72F9 01 60C2 72F9 00 23B2 7275 7271 7271 7275 7271 7271 72F9 00 23D6
0x04040 : 72F9 00 A322 72F9 00 A32E 72F9 00 A3AA 72F9 00 A3B6 72F9 00 A3C6 72F9 00 63A 72F9 00 6316 72F9 00 6322 72F9 01 FCC2 72F9 01 FCF2 72F9 01
0x04060 : 27A 72F9 01 822 72F9 01 82EA 72F9 00 632E 7275 7271 7271 72F9 00 6352 72F9 00 635E 72F9 00 63AA 72F9 00 63B6 72F9 00 63E2 72F9 00 E36 72F9
0x04080 : 01 38FA 72F9 01 B86 72F9 01 B816 72F9 01 B832 72F9 01 B846 72F9 01 B87E 72F9 01 B88E 72F9 01 B8CA 72F9 01 B8D6 72F9 01 7822 72F9 01 7846
0x040A0 : 72F9 01 786E 72F9 01 787A 72F9 01 7886 72F9 01 789A 72F9 01 78BA 72F9 01 78C6 72F9 01 78D2 72F9 01 78DE 72F9 01 78EA 72F9 01 8A86 72F9 01
0x040C0 : 4AA 72F9 00 AFAE 72F9 01 8AC6 72F9 00 EFEE 72F9 00 EFF6 72F9 00 1F2 72F9 00 1F26 72F9 00 1F46 72F9 00 1F52 72F9 00 1F5E 72F9 00 1F6A 72F9
0x040E0 : 00 1F76 72F9 00 1F82 72F9 00 1F8E 72F9 00 9FFE 72F9 00 5F6 72F9 00 5F12 72F9 00 5F1E 72F9 00 5F42 72F9 00 5F62 72F9 00 5F6E 72F9 00 5F7A

Sorry for the poor formatting, I'm still working through making it look better. I was expecting to see the VIN or something in that block .

Can anyone help me try to verify my connections? Is there a offset in eeprom that I should find a certain string? What is the endianness of the data stored?

Any help would be appreciated,
Ivan

[j_ds_au]

What you are reading is Flash, not EEPROM. I suspect VIN data lives in EEPROM. The MCU would address not just Flash, but also EEPROM, RAM, and I/O. The Flash will probably have all $00 or $FF in those address ranges where the MCU would actually be accessing those other devices.

My own ECU/PCM has EPROM instead of Flash (it's older technology). I recently acquired a spare to play with and learn. Reading its "memcal" in a programmer, ie. its EPROM, the resultant binary image did NOT contain any sort of VIN, unless it's disguised. So I figure your ECU/PCM would follow suit. If it contains the VIN, it's not in the EPROM/Flash, but elsewhere, EEPROM (assuming there is some) being the obvious choice.

Joe.

[iblackford]

While flash and traditional eeproms are different technology, they perform the same task, subject to some management by the CPU. (code must be block aligned as flash erasure takes place in block-size chunks, for upgrade purposes it would get really messy to upgrade more than you needed to, possibly overwriting running code).

I don't see any other programmable devices in this design at all, so I'm not sure what it would use to store the information in. Other folks have mentioned that I should see the VIN in code somewhere around 0x4000, given that is where it is on other PCM's.

I'm sure GM has got lots of variants out there, would welcome seeing your design and how it differs.

Thanks, Ivan

[iblackford]

So I have read the entire chip tonight, into a text file from my rs232 program. I tried searching the txt file for my VIN, and I can find bits and pieces of data that, if combined, might form my VIN. However, these are scattered across many memory addresses.

I did a pin by pin mapping of the address bus from the MC68336 to the eeprom when I hooked it up to my programmer, and besides A0 of the CPU not being hooked to anything on the EEPROM (sorry...flash...), it maps perfectly without any of the address swapping that other PCM's have. Am I missing something here or is there another layer of address swapping that could occur, that I'm missing? I feel like I'm nearly there!

[VL400]

I think what j_ds_au is talking about might be confusing things. On our later model EPROM and Flash PCMs (which are 68HC11 8bit and earlier tech than yours) the VIN plus some other stuff is stored on EEPROM internally to the CPU. If your PCM is like the LS1 style 68k PCM then it would be stored on the main flash chip, like you say 0x4000/0x6000 is common block to check.

How are you formatting the dumped file? The VIN is normally stored as ASCII .. http://pcmhacking.net/forums/viewtopic. ... 064#p51659

[iblackford]

Right now I'm storing it in text lines just like this:

0x00000 : 010 10 00 E8EC 00 C8CC 00 C8E0 00 C8F4 00 288 00 281C 00 2830 00 2844 00 2858 00 286C 00 2880 00 2894 00 28A8 00 28BC 00 C8A4
.
.
.
0x7FFE0 : FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF


This is just a quick and dirty output from my programmer..since I'm digging deep and starting from scratch, I need to focus on confirming the hardware is correct before I start formatting the data.
I'm going to work on confirming the databus again...if I have the address bus mixed up, as long as I'm hitting all the addresses, I should be able to parse the data and see where I've messed up.

Ivan

[vn5000]

The data on ls1 memory ic is byte swapped as well , so you will need to byte swap data to make sense of it.

[antus]

If you want to post the data for the whole IC out in whatever text format you have i'll hack together something to convert it to a bin which you can load in a hex editor to better look at it.

[j_ds_au]

I think what j_ds_au is talking about might be confusing things. On our later model EPROM and Flash PCMs (which are 68HC11 8bit and earlier tech than yours) the VIN plus some other stuff is stored on EEPROM internally to the CPU. If your PCM is like the LS1 style 68k PCM then it would be stored on the main flash chip, like you say 0x4000/0x6000 is common block to check.

How are you formatting the dumped file? The VIN is normally stored as ASCII .. http://pcmhacking.net/forums/viewtopic. ... 064#p51659

Did antus read this data directly from Flash or via comm's? If the latter, the MCU could present Flash (or EPROM) at certain address ranges, but other "devices" (eg. RAM or EEPROM) at other address ranges. I seem to recall reading that's what at least some of our local ECU/PCM's do. BTW, my own PCM has an 8 pin DIP package that looks suspiciously like a serial EEPROM. That's not to say the ECU/PCM in question does things similarly, it may well store the typical EEPROM data in Flash, but then again ...

Joe.

[antus]

That data was read via VPW, but I know for sure in the 68332 based '0411 pcms it is in a flash parameter block (as defined by the intel flash datasheet) as well as a second copy used at runtime in built in nvram (or sram). When you key off with power supplied it'll compare the nvram copy to the flash copy, and if required it'll erase the alternate param block, then merge the current copy and the changes from nvram writing to the alternate block. Then it will erase the current copy leaving only 1 active param block. When it next boots it'll use the new location. This is why when eg VIN changes, the param block moves from 0x4000 to 0x6000 or vice versa (or if you write 1 COS with HPT and it changes the key, the block which is usually at 0x4000 will move to 0x6000). If you change the VIN then remove B+ instead of ignition it'll power off before the flash write process runs and the change will not save to flash and it will have reverted at next startup. If you pull the flash chip and read it you will see the param data is on the flash at the same address you see via VPW.