Reading eeprom from delco PCM, MC68336 based

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
iblackford
Posts: 43
Joined: Fri Mar 20, 2015 4:34 am
cars: saturn

Re: Reading eeprom from delco PCM, MC68336 based

Post by iblackford »

So I found that I do have a copy of IDA pro that will disassemble this bin. However, it can't figure out the entry point. Forgive me if I'm new to this, but this is my understanding:

-processor exists reset and looks at 0x000000 for a vector table.
-vector base register can be written to, effectively remapping the vector table

I don't see anything at 0x000000 in my bin, do 0411's have a write to the vector base register at 0x0000?

Ivan
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Reading eeprom from delco PCM, MC68336 based

Post by antus »

Have a look at the ls1 bins here http://pcmhacking.net/forums/viewtopic.php?f=7&t=3#p278

The bottom 512kb looks exactly like that with the reset vector at 0x000000 where it stays. You need to figure out where your flash is mapped at runtime, assuming your bdm read is good.

The whole full read bin looks like rubbish. I cant see any headers, vector tables, stuff that actually looks like code or calibration in there. None of the bottom 512kb looks the same as the first bin you posted. I think either you might still be getting bad BDM reads, or nothing is actually mapped below 0xFF000000. Maybe try the other end of the address space and read 0xFF000000 to 0xFFFFFFFF.

The more I think about it, the more I think your BDM isnt quite right. Im betting the flash and the vectors in the first bin are mapped to 0x00000000 and the fact they are miss aligned and repeated might be something along the lines of the cpu not stopping and still messing with addressing, so your getting data from random locations while you read instead of the intended address. Although in theory it must be stopped if its talking BDM to the pc. This would explain the state of both bins. Or maybe your not in control of the chip select line and for even though the flash is wired to the cpu the data your getting back might be from random other chips as the different chips are selected. See where the CS pin of the flash goes....

From pcmauto.bin. I bet this is your vector table (and a little bit of junk first) but its come up at the wrong address.

Code: Select all

0x00016A60 | 00 7F FF C0 FF FF FF FF FF FF FF FF FF FF 00 10 | ................
0x00016A70 | 80 00 00 00 17 EC 00 00 13 CC 00 00 13 E0 00 00 | ................
0x00016A80 | 13 F4 00 00 14 08 00 00 14 1C 00 00 14 30 00 00 | .............0..
0x00016A90 | 14 44 00 00 14 58 00 00 14 6C 00 00 14 80 00 00 | .D...X...l......
0x00016AA0 | 14 94 00 00 14 A8 00 00 14 BC 00 00 13 A4 00 00 | ................
0x00016AB0 | 13 90 00 00 13 90 00 00 13 90 00 00 13 90 00 00 | ................
0x00016AC0 | 13 90 00 00 13 90 00 00 13 90 00 00 13 90 00 00 | ................
0x00016AD0 | 13 B8 00 00 14 D0 00 00 14 E4 00 00 14 F8 00 00 | ................
0x00016AE0 | 15 0C 00 00 15 20 00 00 15 34 00 00 15 48 00 00 | ..... ...4...H..
0x00016AF0 | 10 E8 00 00 11 0C 00 00 11 7C 00 00 11 C8 00 00 | .........|......
0x00016B00 | 12 10 00 00 12 14 00 00 12 28 00 00 12 48 00 00 | .........(...H..
And here it is again at a different address in the same file. This seems to make random addressing while your reading look likely.

Code: Select all

0x00059A90 | 00 10 80 00 00 00 17 EC 00 00 13 CC 00 00 13 E0 | ................
0x00059AA0 | 00 00 13 F4 00 00 14 08 00 00 14 1C 00 00 14 30 | ...............0
0x00059AB0 | 00 00 14 44 00 00 14 58 00 00 14 6C 00 00 14 80 | ...D...X...l....
0x00059AC0 | 00 00 14 94 00 00 14 A8 00 00 14 BC 00 00 13 A4 | ................
0x00059AD0 | 00 00 13 90 00 00 13 90 00 00 13 90 00 00 13 90 | ................
0x00059AE0 | 00 00 13 90 00 00 13 90 00 00 13 90 00 00 13 90 | ................
0x00059AF0 | 00 00 13 B8 00 00 14 D0 00 00 14 E4 00 00 14 F8 | ................
0x00059B00 | 00 00 15 0C 00 00 15 20 00 00 15 34 00 00 15 48 | ....... ...4...H
0x00059B10 | 00 00 10 E8 00 00 11 0C 00 00 11 7C 00 00 11 C8 | ...........|....
0x00059B20 | 00 00 12 10 00 00 12 14 00 00 12 28 00 00 12 48 | ...........(...H
And then not in fullread.bin at all, despite the fact the first 512kb should be identical.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
iblackford
Posts: 43
Joined: Fri Mar 20, 2015 4:34 am
cars: saturn

Re: Reading eeprom from delco PCM, MC68336 based

Post by iblackford »

So I'm diving deep and trying to figure out the BDM interface...I checked my clock frequency and it's 4Mhz..from what I have read the BDM speed has to be a fraction of this. Going to dig a little further.
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Reading eeprom from delco PCM, MC68336 based

Post by antus »

Thats entirely possible. Try slowing it down to 500khz, and if it works then you can start turning it back up if you need the speed. I actually experienced similar to this once on an AVR via ISP. I was using a speed of 2mhz and it was mostly working but I was getting data corruption. Winding the speed right back solved it.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
iblackford
Posts: 43
Joined: Fri Mar 20, 2015 4:34 am
cars: saturn

Re: Reading eeprom from delco PCM, MC68336 based

Post by iblackford »

I'm not sure how to slow the speed down? I can't seem to go below 1.5Mhz.

I did a few reads...at 1.5Mhz it gives me different data than at 3Mhz.

I'm sure the tool works well once it's running, but it seems to be poorly documented. :(
User avatar
VL400
Posts: 4991
Joined: Sun Mar 01, 2009 2:54 pm
cars: VL Calais and Toyota Landcruiser. Plus some toys :)
Location: Perth, WA
Contact:

Re: Reading eeprom from delco PCM, MC68336 based

Post by VL400 »

Are you using the init button before a read? Unless the script has changed this caused me issues, it inits the PCM but the final command in the script was a reset command - which drops the BDM connection!

Type the commands in manually - 'reset 1' and then 'init'. Try the read button, see if you get correct data then.
iblackford
Posts: 43
Joined: Fri Mar 20, 2015 4:34 am
cars: saturn

Re: Reading eeprom from delco PCM, MC68336 based

Post by iblackford »

I tried what you recommended...I did 3 reads, each at the different speeds available to me.

They all look slightly different, unfortunately. I found there is no init button in the version of software that I'm using...perhaps there are differences and bugs between versions?
User avatar
Holden202T
Posts: 10311
Joined: Sat Feb 28, 2009 9:05 pm
Location: Tenambit, NSW
Contact:

Re: Reading eeprom from delco PCM, MC68336 based

Post by Holden202T »

as I read what VL400 said is to type the init command in manually, not a button.
iblackford
Posts: 43
Joined: Fri Mar 20, 2015 4:34 am
cars: saturn

Re: Reading eeprom from delco PCM, MC68336 based

Post by iblackford »

I did as instructed, typing in the commands manually and the differing reads were the result.

I'm working with the developer of the USBDM to make this work. He suggested to put a very strong pull on the RESET pin, 150ohm to 12V. If this were to work, it's only masking the real problem. I tried it also and it did not work.

He's going to remote in to my computer this evening and work with it, hopefully he can add support for this.

Ivan
iblackford
Posts: 43
Joined: Fri Mar 20, 2015 4:34 am
cars: saturn

Re: Reading eeprom from delco PCM, MC68336 based

Post by iblackford »

So I didn't make much progress on the USBDM, my times to get assistance haven't lined up yet with the USBDM guy. I did have some minor breakthroughs though:

-I found that the reason the MC68336 was loading the bus is because I was not asserting the TSC pin at the right time. I found some documentation that said I needed to assert it while the CPU was running
-I did a complete read using my homemade programmer in this state and compared it to what I had read previously...it was nearly identical except for a dozen bytes or so throughout the file.
-The data wasn't the same at all with the blocks I had read through the BDM..I know from looking at the file that some data was being read correctly, I was just likely reading the wrong addresses.
-I dug into reading the MFR ID and device ID from the EEPROM, I hadn't tried to read this previously through my programmer on this chip. I found that the manufacturer ID (089h) was reported correctly, but the device ID, 889D, was being reported as 119D. This didn't make sense to me at all, I checked my code and everything appeared to be correct.

Then I looked more closely at the Arduino, and realized that their pin mapping sucks. Essentially D7 & D0, D6 & D1...etc...were swapped in the high byte of the word. A quick rewire and I read the eeprom again. This time, I can see similar patterns to what I was reading from the BDM.

It's still in a poorly formatted ascii format, but if anyone feels like parsing it and helping me out, I wouldn't complain. :):)

Thanks for all the help so far, I hope the documentation of my journey will help some folks in the future.

Ivan
Attachments
pcmautoascii.txt
(2.38 MiB) Downloaded 288 times
Post Reply