the entropy bites on a ROM emulator

[legacy]

A dude on eBay has recently sold me a Softec ROM emulator, which I am using to emulate a 27C010 (128Kbyte, 8bit) ROM on an SBC board. The CPU panics immediately, and after two days of digging around, I figured out that the emulated image is not equal to the file I pass to the ROM emulator but rather, and, still worse, it has not a random corruption which can be addressed to the cable, or to the socket, but rather something that always happens at the same address locations

emulated ROM

Code: [Select]

00900200  56 8A 10 12 48 80 02 80  00 00 00 01 66 04 4E BA   V...H.......f.N.
00900210  00 08 4C DF 0C 00 4E 75  48 E7 38 00 28 3C AA AA   ..L...NuH.8.(<..
00900220  AA AA 26 3C 55 55 55 55  0C 84 AA AA AA AA 67 04   ..&<UUUU......g.
00900230  4E BA FF 18 0C 83 55 55  55 55 67 04 4E BA FF 0C   N.....UUUUg.N...
00900240  13 FC 00 AA 00 4F[02]F0  13 FC 00 55 00 5F[83]F0   .....O.....U._..
00900250  0C 39 00 55 00 4F[00]F0  66 04 74 05 60 16 13 FC   .9.U.O..f.t.`...
00900260  00 08 00 1F FF F0 13 FC  00 02 00 7F FF F0 14 39   ...............9
00900270  00 1F[C3]F0 10 02 48 80  48 C0 72 05 B0 41 67 0E   ......H.H.r..Ag.

image passed to the ROM emulator

Code: [Select]

00000200  56 8A 10 12 48 80 02 80  00 00 00 01 66 04 4E BA   V...H.......f.N.
00000210  00 08 4C DF 0C 00 4E 75  48 E7 38 00 28 3C AA AA   ..L...NuH.8.(<..
00000220  AA AA 26 3C 55 55 55 55  0C 84 AA AA AA AA 67 04   ..&<UUUU......g.
00000230  4E BA FF 18 0C 83 55 55  55 55 67 04 4E BA FF 0C   N.....UUUUg.N...
00000240  13 FC 00 AA 00 4F[FF]F0  13 FC 00 55 00 5F[FF]F0   .....O.....U._..
00000250  0C 39 00 55 00 4F[FF]F0  66 04 74 05 60 16 13 FC   .9.U.O..f.t.`...
00000260  00 08 00 1F FF F0 13 FC  00 02 00 7F FF F0 14 39   ...............9
00000270  00 1F[FF]F0 10 02 48 80  48 C0 72 05 B0 41 67 0E   ......H.H.r..Ag.

(differences are marked within "[", "]" )

Why does it happen? ...   This is the big question. This device is a MultiROM device made by Softec Microsystem, and their software comes with a diagnostic, which says "no problem found", but it says lies since we have a serious problem here.

Probably, in my opinion, the diagnostic just tests the cable, or the interface, rather the internal RAM used to store the emulated ROM.

[CJay]

Upload a ROM image with just $00 in it and see if the corruption re-occurs.

Then try $AA and then $55

[capt bullshot]

This is a systematic failure -> the emulator is borked, get a replacement from the vendor. If the new one shows the same systematic failure, it's either a bad design or something strange that happens at your target only.

Good point of CJay, try to do some systematic tests.

[legacy]

Upload a ROM image with just $00 in it and see if the corruption re-occurs.
Then try $AA and then $55

with just 0x00, it reports corruption at addresses: 00900240, 00900250, 00900270
I still have to test with 0xAA and 0x55, but it seems the damage is regarding the internal RAM used for emulating.

[CJay]

I think you're right, I think it's the RAM in the emulator causing the problem.

$AA and $55 are binary 01010101 and 10101010 respectively so can show up stuck bits/address lines and allow you to diagnose the problem but if you've only just bought it, get a replacement.

[legacy]

I have just emailed to Softec Microsystem signaling the problem, I am waiting for their reply if someone will care about an EOL product.  I bought it on eBay and the seller doesn't have more in stock, he can only refund.

get a replacement.

I have also tested the SBC with a Moates Ostrich2 ROM emulator and it works perfectly, so I am starting to think that the Softec Microsystem is seriously damaged, and I wonder if it's possible to repair it because it would be a pity to trash it.

[amyk]

Are they all FFs becoming something other than FF ?

I notice that around those addresses the surrounding values also have lots of 1 bits set. It could be a bad decoupling capacitor.

[capt bullshot]

I notice that around those addresses the surrounding values also have lots of 1 bits set. It could be a bad decoupling capacitor.

Didn't know it was an EOL device. So fixing it on your own is a valid option, most probably I'd take that turn under these circumstances.

Yes, bad decoupling can cause all kinds of flipped bits, most prone when many address / data lines change their state from "0" to "1" (or vice versa) at the same time. So the transition from "data FF @ address 1FFFF" to "00 @ 20000" is more vulnerable than e.g. "55 @ 1A653" to "AA @ 1A654" (since there are lesser bits changing, and changing adjacent data lines to opposite states might compensate to some extent).

[legacy]

I will post logs with the suggested tests with 0x55 and 0xaa


I have just got an email back with the response: the Italian partner "Veratim" has just said that www.softecmicro.it is dead and about their EOL products .. well all the  engineers assigned to the MultiROM are retired.

[duak]

I'm not familiar with this device.  Is a cable used between the emulator and the SBC or does the emulator plug directly into the SBC?   If the package is a DIP, extension with only one GND and one power pin is marginal.  Are there any extra ground or power connections available on the emulator to improve connectivity with the SBC?

[CJay]

I will post logs with the suggested tests with 0x55 and 0xaa


I have just got an email back with the response: the Italian partner "Veratim" has just said that www.softecmicro.it is dead and about their EOL products .. well all the  engineers assigned to the MultiROM are retired.

Well if you do get to keep it and want to repair, post up pics of the internals here, even if we can't help, it's always nice to have a reference, sometimes it helps others in the future.

[TerraHertz]

Presumably it will have one or more static RAM chips. Have you opened it up? Are they through hole?
If so, desolder them, put in sockets, and swap them around. Do the bad locations stick with one of the RAMs?

Is it one of these?   https://www.esis.com.au/Programmers/Multirom_flyer.pdf

[CJay]

Is it one of these?   https://www.esis.com.au/Programmers/Multirom_flyer.pdf

Ooh, that's nice, I like that.

[legacy]

I have to emulate one of these. It's equal to 27C010.
It's 128Kbyte, 8bit, and it's supported by Softec MultiROM.

[legacy]

[capt bullshot]

Check the electrolytic capacitors for ESR and capacity or check the supply rail (I guess there's 5V only in this box) for excessive ripple.
The chips made by Alliance are the RAM chips - I remember FLASH chips by that make that were very unreliable.
On the right hand side, there's a galore of protection resistors, check these for value and cracked solder joints.

[MadTux]

Soldering a new SRAM chip shouldn't be that difficult, IMO the most probable cause of failure.
512Kx8, 3.3V SRAM also shouldn't be too hard to find, I even might have some.

Worst case scenario would be some flipped bits in the Altera CPLD/FPGA chips, since these are flash/EEPROM based.

[legacy]

512Kx8, 3.3V SRAM

From Alliancememory, this is the datasheet for the AS7c34096.

• AS7C4096 is the 5V version
• AS7C34096 is the 3.3V version

I wonder if a cell of a static ram can die this way ... and for which reason ...

Worst case scenario would be some flipped bits in the Altera CPLD/FPGA chips, since these are flash/EEPROM based.

And the assigned engeears are all retired, so there is no way to get the bistream for re-programming.

[joeqsmith]

Have you tried using the upper data bits?  If you only need 8 you may be alright for now. 

[legacy]

Have you tried using the upper data bits?

No 

The upper data bits (which has a second cable) iss for emulating a bigger (>1MByte) ROM, or a 16bit bus one. In my case, I need to emulate a 27C010, which is 8bit data bus, and 128Kbyte of size.

The diagnostic-cable, anyway, uses both the connectors. I don't know what tha diagnostic software does, it requires to plug a special cable, and does some test. It says "all tests passed", but it doesn't seem accurate.

[ebastler]

Have you tried using the upper data bits?

No 

The upper data bits (which has a second cable) iss for emulating a bigger (>1MByte) ROM, or a 16bit bus one. In my case, I need to emulate a 27C010, which is 8bit data bus, and 128Kbyte of size.

Sure, 16-bit systems are what the upper bits were meant for. But you could still connect those 8 upper bits to your 27C010 data lines, right? It would entail making a custom cable, but if those bits work, I think Joe's idea has merit.

[legacy]

looking at errors ... it seems there is a common repeated pattern

4F[02]F0 -> 4F[FF]F0
5F[83]F0 -> 5F[FF]F0
4F[00]F0 -> 4F[FF]F0
1F[C3]F0 -> 1F[FF]F0

cells preceded by something that ends with "0x*F" and followed by something that begins with "0xF*" seem to be affected.

Maybe it means something 

[capt bullshot]

This thing is connected through the printer port (LPT)?
One way to transfer 8-Bit data and other control stuff through an 8-Bit port is to encode part of the available data range into a sequence of multiple bytes, having the goal to embed control codes.
random example:
data     transferred
0xFD   0xFD
0xFE    0xFE 0x00
0xFF    0xFE 0x01
so 0xFF never appears in the normal data stream,
now one can embed control codes by preceding them with 0xFF

Maybe this is some kind of a control sequence that isn't properly encoded or decoded.
Just a wild guess.

[legacy]

This thing is connected through the printer port (LPT)?

Yes! The manual requires to the the LPT in bidirectional-mode.
I did it in the PC-BIOS. I will try a better cable, and on a different PC.

[amyk]

looking at errors ... it seems there is a common repeated pattern

4F[02]F0 -> 4F[FF]F0
5F[83]F0 -> 5F[FF]F0
4F[00]F0 -> 4F[FF]F0
1F[C3]F0 -> 1F[FF]F0

cells preceded by something that ends with "0x*F" and followed by something that begins with "0xF*" seem to be affected.

Maybe it means something 

As mentioned above, there are a lot of "1" bits in those corrupted patterns, so they do represent extremes in power draw and bad signal integrity is likely to show up there. It could even be something like a bad connection leading to an IC being powered through its signal pins, something that Dave has even made a video on: https://www.eevblog.com/forum/blog/eevblog-831-power-a-micro-with-no-power-pin!/