Electronics > Microcontrollers

Need help dumping the ROM in a failing 80C49 (MCS-48)

(1/12) > >>

trondl:
Hi!
This is a continuation of this thread: https://www.eevblog.com/forum/repair/roland-sde1000-repair-guidance-needed!/
I chose to continue here as I now have a different problem.

First of all, an 80C49 with maskROM that is _very_ unlikely to have the copy protection enabled,
is failing and needs to be chilled to bellow freezing temperatures (-5 degC outside here in Norway) to work "in situ".
I say unlikely because most of the other ROM's from the same producer and era have been dumped and are for sale on the interwebs

I have built this Arduino shield and have verified it's function by programming a 8749 with success:
http://www.mattmillman.com/projects/hveprom-project/an-easy-to-build-mcs-48-8748-8749-8741-8742-8048-8049-programmer-reader/#comment-96692

The problem is that the MCU is failing and I just get semi-random garbage in the read-out, even in the same environment as when it is stable and working in the unit to be used in.
When probing the D pins on the MCU during the dump, I get steady pulse trains on pins 0-3, but on 4-7 it looks more like bursts.

Worth noting here is that in the Windows GUI application for the project gives me a warning about the Arduino VIN pin being low.
It should be 12V but I get 11,4V.
This caused no issue when programming the 8749.

My theory is that since it is failing, the access time is much higher than ideal for a normal read-out.
A similar story that almost proves my theory is here: https://forums.arcade-museum.com/threads/stumped-random-eprom-readings-need-input-from-eprom-gurus.320383/

Now, the project is open source, I've spoken to the author, but he is understandably not available to commit to this issue.
He guided me to try to add extra delays in the _read_ routine, hopefully not messing up the timings:
https://github.com/inaxeon/eightoduino/blob/master/app_hveprom/pgm_mcs48.c

My problem is that my programming skills are subpar to put it mildly.
Which lines are relevant to the read delay routine?
Is it somewhere between lines 49 to 61, or is it 107 to 110?

You can exclude the extra sections for programming/writing and the odd 8755 MCU.
All I need is a starting point at slowing down the dump to a point where I can hopefully get a stable transfer.

The XTAL attached to the mcu on the shield is 4MHz.
I think page 26 in this document has the min-max timings, but it's a bit beyond me:
https://archive.org/details/grokking-the-mcs-48/page/n25/mode/2up?view=theater

Thanks in advance!

amyk:
AFAIK there is, unlike the programming pulses, no maximum times for readout, so you should be able to go as slow as you want.

james_s:
Is that the new one you programmed that is giving you errors when reading out? Usually the problem is the other way around, read out works fine but fails when run at full speed in the intended application.

trondl:

--- Quote from: james_s on November 29, 2021, 01:10:55 am ---Is that the new one you programmed that is giving you errors when reading out? Usually the problem is the other way around, read out works fine but fails when run at full speed in the intended application.

--- End quote ---

No, it is the failing one that is giving no valid readout, even when cold, but works "in situ" when cold.

trondl:
The author of the shield verified that lines 107 and 109 (pgm_mcs48_delay_4tcy, pgm_mcs48_delay_pre_read) are mostly responsible for the reading section.
Now, I've experimented a bit with both long and veeery long delays in the reading,
And,
I'm starting to see some expected results!
I have another ROM dump from the same producer, and they pad the remaining data with 00 01 02 03 all the way to FF repeated.
The problem is that some bits (sometimes bit 5 and 6, sometimes just bit 5) stay high 99% of the time, and that the data looks to be out of sequence.
Before half way through the dump I expect to see the padding data, but I get them either repeated or out of sequence,
to illustrate an example: 00 02 02 01 03 05 06 05 05 04

Any ideas here?
May it be trouble with the addressing as well?

Navigation

[0] Message Index

[#] Next page