Reading eeprom from delco PCM, MC68336 based

[antus]

While im at it, this is the tool ive written to reverse engineer the guts of the 0411. This, and pulling the chip are how I can be sure. The pcm this thread is about is an earlier revision but a similar platform. How similar it is, is for us to figure out.

Note that the box on the right of this tool still says eeprom. That heading was typed in before I figured out there was not an eeprom and I only just noticed it now!

[iblackford]

Very cool...I did a bunch more troubleshooting on it lastnight..I found that some data bits weren't going full swing, they were only going to just over 2V, which is just about the Vih threshold...I suspect this is what is causing the data to look all garbled. Something on the data bus is loading it.

My process for reading and writing to the chip is to do it onboard, as I have a flex circuit, and I'm sure I risk damage to the flex trying to remove and resolder the flash. To this end I've tried to isolate it by pulling the TSC pin of the processor to 1.6*Vdd. This is supposed to, according to documentation, tristate all the pins on the MC68336 effectively taking it out of circuit. It doesn't appear to be working for me, or there is some other prerequisite that I need for this to work. I'm still investigating.

I appreciate the offer of formatting my dumped file, but I think it's useless at the moment until I solve this problem.

I did break down and order a USBJTAG bdm tool, as I need to get this hack complete. I still want to learn from this though. My homemade EEPROM programmer is largely complete, it just lacks a nice windows gui to interface with it. I'll continue to work on this as time permits.

In the meantime I think what would be nice is to have a more open source BDM tool to interact with the flash. Has anyone used any other BDM tools than USBJTAG?

Thanks, Ivan

[antus]

Ive only used usb bdm nt from usbjtag.com for bdm. for jtag ive got a segger jlink interface, comes with good software but not usefull for this application.

Just looking at your output formatting again i see your printing 16bit words with no padding. Try using %04X as your format string so you always get 4 hex characters with zeros for padding. Should make it line up better.

[iblackford]

Agreed on the padding, right now I'm just dumping it from the serial port, a quick and dirty way to get the data from the eeprom, I'll focus more on this once I can figure out why the data bus is being loaded down.

I found some bdm info that I'm going to look a little more into:

http://cmp.felk.cvut.cz/~pisa/#m683xx

I'll get this one way or the other!

[antus]

Cool stuff. Bdm would be easyer to connect and if you can get the flash write support working that'll open a lot of doors!

[j_ds_au]

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.

Well, that's pretty conclusive!

Thanks, antus.

Joe.

[j_ds_au]

Very cool...I did a bunch more troubleshooting on it lastnight..I found that some data bits weren't going full swing, they were only going to just over 2V, which is just about the Vih threshold...I suspect this is what is causing the data to look all garbled. Something on the data bus is loading it.

OK, just over Vih is not ideal, but in reality, the threshold voltage is likely to be about 1.4V, so unless you've got a lot of noise, you shouldn't get too much garbled data. Are there any address decoders or buffers between the MCU and the Flash? They probably won't go tri-state when the MCU does.

Joe.

[iblackford]

Direct connection. I can't see any reason they would need to put anything in the way, and they didn't...haha. It's a pity I can't seem to tristate it, but the BDM is a more elegant option anyways.

[j_ds_au]

Direct connection. I can't see any reason they would need to put anything in the way, and they didn't...haha. It's a pity I can't seem to tristate it, but the BDM is a more elegant option anyways.

Well, the tri-state voltage is fairly tight, could that be the problem? Or maybe you've got some static damage?

Yeah, BDM would be way more elegant! I suppose it's like the debugWire interface on AVR's (I'm not too familiar with the 68300 family)?

Joe.

[iblackford]

Direct connection. I can't see any reason they would need to put anything in the way, and they didn't...haha. It's a pity I can't seem to tristate it, but the BDM is a more elegant option anyways.

Well, the tri-state voltage is fairly tight, could that be the problem? Or maybe you've got some static damage?

Yeah, BDM would be way more elegant! I suppose it's like the debugWire interface on AVR's (I'm not too familiar with the 68300 family)?

Joe.

Not sure that I quite understand what you mean by "tri-state voltage is fairly tight". Do you mean the voltage I'm applying to TSC to tristate the IC? Then yes, It's poorly documented. I did go above 1.6Vdd to around 8.4V (Vdd is 5). Still no change.

As far as static, I always find static to be the go to cause when one can't figure out the problem. I work with high brightness projectors, and during the lamp strike event poorly designed electronics will usually reset. To test our designs against this I test them with an ESD gun. 15kV direct contact discharges direct to a net on the PCB. An unprotected micro often loses it's mine and resets, but I have never experienced permanent damage from this.

I ordered a 16channel logic analyzer a few weeks ago, I received it lastnight, I'll debug a little more with this tonight while I wait for my BDM to show up.

Ivan