Winbond - you get a cookie.

[WebClaw]

Seriously guys, this was still readable with some work...

Wow...

Attachments

[Zero Alpha]

Did someone bring this to you because they damaged it with very bad soldering skills? and you had to fix it with that jumper wire?

[WebClaw]

I would exempt the word "skills"; but yes.
I've never seen a ROM module so puffed up and still readable.

[Zero Alpha]

Yeah thats a crime scene but well done for getting it to work again.

[fzabkar]

I have an idea for recovering these ROMs when the Vcc or ground pins are completely inaccessible.

I recall that in one blog someone needed to cut both the Vcc (8) and Hold* (7) pins to prevent a USB-SATA bridge IC from detecting its external SPI flash. It appears that the IC obtained its power from the Hold* pin via an internal pullup diode. I suspect that WP (3) could similarly provide a path to ground via an internal pulldown diode in those cases where the Gnd pin (4) has been damaged.

[WebClaw]

I have an idea for recovering these ROMs when the Vcc or ground pins are completely inaccessible.

I recall that in one blog someone needed to cut both the Vcc (8) and Hold* (7) pins to prevent a USB-SATA bridge IC from detecting its external SPI flash. It appears that the IC obtained its power from the Hold* pin via an internal pullup diode. I suspect that WP (3) could similarly provide a path to ground via an internal pulldown diode in those cases where the Gnd pin (4) has been damaged.

Cool beans, I just tried that. ROM did read, but hugely corrupted.

I don't think it's a good enough ground. See attached.

Thanks for the tip, maybe someone could post process the ROM; or at least pull out the RAP w/some multiple reads.

Attachments

41.bin.zip

(513.8 KiB) Downloaded 218 times

[fzabkar]

If you have a 1.8V ROM, you may need to select a 2.5V supply to account for the voltage drop across the diode.

Edit:

I just noticed that your case involves the ground pin. Sorry. Maybe a level translator is needed. I did something like this 30 years ago when I needed to buffer a sick output pin on a VGA controller IC.

Edit #2:

Can you upload the good ROM so that we can see where the differences are?

[WebClaw]

If you have a 1.8V ROM, you may need to select a 2.5V supply to account for the voltage drop across the diode.

Edit:

I just noticed that your case involves the ground pin. Sorry. Maybe a level translator is needed. I did something like this 30 years ago when I needed to buffer a sick output pin on a VGA controller IC.

Edit #2:

Can you upload the good ROM so that we can see where the differences are?

Sure.

Attachments

45.zip

(507.39 KiB) Downloaded 266 times

[fzabkar]

The data looks good but the problem is that it is being read from the wrong address. Your programmer appears to dump the ROM in 0x4000-byte chunks. At the start of each chunk, the software sends an address plus a read command to the ROM. The clock appears to be fine because there are no bit-shifts in the output. It seems that the data on the input pin of the ROM is not being reliably processed. For example, when the programmer asks the ROM to begin dumping data from address 0x4000, the ROM misinterprets this as 0x4006.

The solution is to dump the ROM as one long stream, without resynching the address at each chunk. Also choose a ROM type that has twice the capacity of your patient. In this way the ROM will be dumped twice, without a break in between. This will account for those cases where address 0 is misinterpreted.

[fzabkar]

I have another solution. Dump the ROM 10 times, say, then compare each 0x4000-byte block across all of the dumps. If a particular block is consistent in 5 dumps, say, then assume it is good and add it to the repaired ROM. Do this for all blocks. I could probably write a simple tool to do this.

[WebClaw]

I have another solution. Dump the ROM 10 times, say, then compare each 0x4000-byte block across all of the dumps. If a particular block is consistent in 5 dumps, say, then assume it is good and add it to the repaired ROM. Do this for all blocks. I could probably write a simple tool to do this.

I was using this software:
https://www.batronix.com/shop/software/ ... index.html

And these readers:
https://www.batronix.com/shop/programme ... go-II.html
https://www.batronix.com/shop/programme ... index.html <-- 1.8V support

I don't think that this reader that that ability. Good comment re: double size I will note and remember that.

Same results with ROM RUS Pro (a dolphin reader).

I did try the successive reads. That is how I was able to read it out, as the filename implies it did take 45 attempts to read the ROM properly.

I had to use F3 explorer to piece results together.

[fzabkar]

I know that an old version of Bus Pirate can dump a device as a continuous stream. I assume that the current version still does this.

[fzabkar]

I wonder if there is an opportunity here:

Prog-Express can be remote controlled by other software with command line parameters and script files

Edit:

I just had a look at the manual. There don't appear to be any commands that would give us the kind of control that we need.

[fzabkar]

It might be worth trying a 2.5V supply. That would shift the threshold at which a 1 becomes a 0 and vice versa.

If you can upload all your dumps, perhaps I could automate a reassembly procedure.

[WebClaw]

I'll take this link down once you download it.
https://download.icubedev.com/start/?fi ... FIXING.ZIP

I'll try 2.5V tomorrow. Would be nice to share a new technique if this can be done w/o a ground pin.

[WebClaw]

Still corrupt:
[removed / not working correctly]


and called by

Code:

import serial
import time

def read_rom_data(serial_port, baud_rate, output_file):
    ser = serial.Serial(serial_port, baud_rate)
    time.sleep(2)  # wait for the serial connection to initialize ( sleep 1 fails)

    ser.write(b'R')  # Send the read command Arduino P1

    with open(output_file, 'wb') as file:
        for i in range(1024 * 1024): # double?
            data = ser.read(1)
            file.write(data)

    ser.close()
    print(f"ROM dumped to {output_file}")

if __name__ == "__main__":
    serial_port = 'COM3'  # using PS to USB port 2
    baud_rate = 115200
    output_file = 'rom_dump.bin'

    read_rom_data(serial_port, baud_rate, output_file)


last attempt:

Code:

import serial
import time
import os

def read_rom_data(serial_port, baud_rate):
    ser = serial.Serial(serial_port, baud_rate)
    time.sleep(2)  # Wait for the serial connection to initialize

    ser.write(b'R')  # Send the read command to the Arduino

    data = ser.read(1024 * 1024)
    ser.close()

    return data

def compare_rom_reads(reads):
    reference = reads[0]
    for read in reads[1:]:
        if read != reference:
            return False
    return True

if __name__ == "__main__":
    serial_port = 'COM4'  # try 2nd adapter
    baud_rate = 115200

    reads = []

    for i in range(10):
        print(f"Reading ROM... Attempt {i+1}")
        rom_data = read_rom_data(serial_port, baud_rate)
        reads.append(rom_data)
        time.sleep(1)  # Wait a second between reads

    if compare_rom_reads(reads):
        print("All ROM reads are identical.")
        output_file = 'rom_dump.bin'
        with open(output_file, 'wb') as file:
            file.write(reads[0])
        print(f"ROM data dumped {output_file}")
    else:
        print("ROM reads are not identical.")
        for idx, data in enumerate(reads):
            output_file = f'rom_dump_attempt_{idx + 1}.bin'
            with open(output_file, 'wb') as file:
                file.write(data)
            print(f"ROM data from attempt {idx + 1} has been written to {output_file}")


[fzabkar]

I was wrong about the clock. The ROM does sometimes miss a clock pulse. This results in a bit shift.

45.bin

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000BDEC0                                         02 98 F3
000BDED0  01 00 01 00 01 00 01

10

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000BDDE0        0A 63 CC 04 00 04 00 04 00 04

This data is shifted by two bits:

Code:

02 98 F3 01 00 01 00 01 00 01
0A 63 CC 04 00 04 00 04 00 04

0b 0000 0010 1001 1000 1111 0011 0000 0001
0b 0000 1010 0110 0011 1100 1100 0000 0100