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

[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]

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.

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?

[wraper]

Since MCU is temperature dependent, likely it's also voltage dependent. So I suggest playing with voltage, like powering MCU from 5.5V or 4.5V instead of 5V and checking if it helps.

[james_s]

So the new one you programmed does read out correctly?

It's possible that the failing one does in fact have the code locked if it has that feature. It's also possible that it has failed such that part of whatever is required to read out the code has failed completely. As was mentioned above you could try playing with the voltage but there is some risk there, you're probably fairly safe to go up as high as about 6V, maybe 6.5V for a modest period.

[wraper]

It's possible that the failing one does in fact have the code locked if it has that feature.

If code locked, you won't get changing readout.

[trondl]

So the new one you programmed does read out correctly?

It's possible that the failing one does in fact have the code locked if it has that feature. It's also possible that it has failed such that part of whatever is required to read out the code has failed completely. As was mentioned above you could try playing with the voltage but there is some risk there, you're probably fairly safe to go up as high as about 6V, maybe 6.5V for a modest period.

The 8749 programmed and verified, yes, and there is a hardware test in the application, also verified all checks.

The weird thing is that when I delay the readout, I'm starting to see expected padding data patterns compared to a known good dump for another product, although out of sequence and sometimes echoed, as if the correct address hasn't been decoded.
Also sometimes, some bits stay high 99% of the time.
Sometimes not.

To me, it all seems like the data isn't ready on the D0-7 pins when being read.

I probed the Reset pin during a dump, and it is in bursts pulled 8 times high very fast, maybe too fast for it to properly reset.

I may have to learn some C code and insert some delays for the reset and addressing, as delaying the reading clearly gives some results.

[trondl]

It's possible that the failing one does in fact have the code locked if it has that feature.

If code locked, you won't get changing readout.

Thanks for verifying!

[amyk]

was mentioned above you could try playing with the voltage but there is some risk there, you're probably fairly safe to go up as high as about 6V, maybe 6.5V for a modest period.

80C49 is on an old thick oxide large-geometry process, in fact according to datasheet typical recommended VCC/VDD is 5V+/-20% (4-6V) and absolute maximum is 7V(!) I wouldn't go over 7V but Intel tends to be quite conservative with the maximums, for reliability purposes.

[james_s]

About 20 years ago I had a classic arcade cabinet that wouldn't boot unless the 5V was cranked up to close to 7V. In retrospect it was probably a faulty ROM or something but at the time I didn't really know much about digital stuff and the way the board stack was set up made it a nightmare to work on. It ran for a couple years like that until I sold it.

[trondl]

I think I'll play with delays, rather than risk frying it for now.
But a last resort is better than none!
Thanks.

It's seems that I can insert some delays after the address latching at line 464 in the code.
I'll give that a go first.
Now, how to insert delays in C code...

[abyrvalg]

Inserting delays example: _delay_us(20); line will do 20 microseconds delay. _delay_ms(20); will do 20 milliseconds.
This assumes you are using a "normal" (AVR-based) Arduino, not the 80x86 one also mentioned in that project.

[trondl]

Inserting delays example: _delay_us(20); line will do 20 microseconds delay. _delay_ms(20); will do 20 milliseconds.
This assumes you are using a "normal" (AVR-based) Arduino, not the 80x86 one also mentioned in that project.

Thanks a bunch!
AVR compiler, yes

[james_s]

It's quite safe to bump the voltage up a bit, say 5.5-5.75V, it's just going beyond the absolute maximum in the datasheet that you should save as a last resort.

[dl6lr]

I often found it helpful to *lower* the Vcc voltage during read on aged EPROM devices as it lowers the threshold of the read amplifiers. Successful programming is therefor often verified with *higher* voltages whereas the blank check should be performed with the minimal voltage. So you may have a better chance by lowering the voltage of the 8049 to i.e. 4.75V or 4.5V and reading them slowly in the cold...

[artag]

The XTAL attached to the mcu on the shield is 4MHz.

That's the XTAL on the arduino-based programmer, not the original Roland board ? I guess if the programmer has a crystal then it's performing at least a part of the programming/verifying using the actual CPU. There may be some internal ROM that handshakes the data in from the pins and writes it to EPROM. So what's the XTAL on the Roland board ? Does it run slower than 4MHz ? Can you reduce the clock speed on the programmer ?

[trondl]

I often found it helpful to *lower* the Vcc voltage during read on aged EPROM devices as it lowers the threshold of the read amplifiers. Successful programming is therefor often verified with *higher* voltages whereas the blank check should be performed with the minimal voltage. So you may have a better chance by lowering the voltage of the 8049 to i.e. 4.75V or 4.5V and reading them slowly in the cold...

That sound a bit safer than going over!

I've now tried inserting huuuge (10ms) delays where I can, and still get a 100% verified dump on the known good 8749.
Time to dump is about 5mins.
I still get the same semi-random results.

Looks like Vcc mods are in order.
Starting at 4.5V

Now, the next problem is my little knowledge of connecting up multiple psu's with regard to the ground/common.
Both my laptop, 12V/3A generic arduino brick and my DIY "lab" psu I built years ago during education are not earth referenced.

Could this cause any problems?

In circuit on the shield, VCC is tied with T1, /SS and /INT/[CS] to 5V.
Should I lift the leg for VCC out of circuit and apply the "lab" psu between VCC and VSS?

Shield schematics attached.

The XTAL attached to the mcu on the shield is 4MHz.

That's the XTAL on the arduino-based programmer, not the original Roland board ? I guess if the programmer has a crystal then it's performing at least a part of the programming/verifying using the actual CPU. There may be some internal ROM that handshakes the data in from the pins and writes it to EPROM. So what's the XTAL on the Roland board ? Does it run slower than 4MHz ? Can you reduce the clock speed on the programmer ?

XTAL in Roland is 11MHz.
Arduino shield is 4MHz.

That's the odd thing, since it works when cold in the Roland, but not in the shield.

[abyrvalg]

You’ve mentioned an observable difference between D0-3 and D4-7 during dump. Try probing them in the original device (and cooled) - what’s the difference?

[trondl]

You’ve mentioned an observable difference between D0-3 and D4-7 during dump. Try probing them in the original device (and cooled) - what’s the difference?

In circuit, the DB on the mcu is controlling the display and input switches/latches, so there wouldn't be much data to verify except functionality.

Now, on to my next endeavor, under/over-voltage on the VCC pin.
The Arduino is powered by an external 12V/3A psu and connected to a laptop, all floating ground/common.
If I were to lift the VCC pin out of the shield and apply a secondary PSU (also floating) between VCC and VSS which by the way is also connected to the shield ground/common, could it cause any bad "feedback" into the Arduino shield?

[trondl]

Or should I lift both the VCC and VSS pin and connect them to the external PSU with floating ground/common?
Don't want to fry anything by accident here.

[james_s]

Just connect the ground of your PSU to the ground of your programmer, provided the PSU is something with an isolated floating output everything will be fine.

[trondl]

Just connect the ground of your PSU to the ground of your programmer, provided the PSU is something with an isolated floating output everything will be fine.

Thanks for verifying!

[m k]

Why 10ms delay is huge?
If it needs a week then it takes a week.

Reading subroutine starts from line 440 and its loop from 452.

461-464 is putting the address out.
There you have the first 4tcy delay.

466 changes the direction of a port, I guess.
467 has the next delay.

484 then is the actual read.

From pgm_common.c
uint8_t pgm_read_data(void)
{
#ifdef _M8OD
    return (uint8_t)cpld_read(PORTC);
#endif /* _M8OD */

#ifdef _MDUINO
    return DATA_PIN;
#endif /* _MDUINO */
}

Indented lines are actual read commands.
One for _M8OD and other for _MDUINO.

So despite all your pre read delays you're still actually reading like zap, it's done.
You should replace that 484 line with your own reading procedure.
Address is there and is not changing so you can read as many times as you like.
Maybe you should read 100 times and analyze what you get.
You can replace that 484 line with how ever more stuff also, so you can put there read, delay, read, delay and so on.

Maybe you should modify the board and read using analog pin.
If you have only one analog pin then probably easiest is to read one bit thru the chip and then manually connect it to the next bit.
Though it's probably not helping with weak output.