tomnisbet / tommyprom Goto Github PK

I've breadboarded TommyPROM, but I am having issues getting it working and don't understand enough to find the fault myself.
I've downloaded the firmware to my Boarduino, and I can read the contents of EEPROM's but attempts to write fail.
Is there a way I can contact someone to help me?

Cheers,

 John Gay

Hello,
How to use the code for 27C256?

The first character of the ASCII in the memory dump command is missing. When the addresses were extended from four digits to five, the dump command was not adjusted. The ASCII part of the memory dump needs to be shifted over by one character so that the trailing space character from the last byte of the hex dump does not overwrite it.

can it run in arduino mega? because mega has alot of gpio, no need other ic.

The original TommyPROM code used the XModem-CRC variant of the protocol that calculates a 16-bit CRC instead of the default 8-bit checksum. While this does perform a more thorough error-check, it is not really necessary when doing communication over a 3-foot USB cable. While the CRC version of XModem is well-supported in TeraTerm for PCs, it is problematic with minicom and other Linux software that relies on the sz/rz package.

The default code will now use basic XModem instead of XModem-CRC for file transfers. For compatibility, the XModem-CRC code is still available as a compile-time option.

See this thread for the journey: https://www.reddit.com/r/beneater/comments/j83zu1/using_tommyprom_28c256/

I am trying to burn an image to a 28C256, but it is not working.

MacOS Sonoma 14.3
minicom version 2.9
TommyPROM 3.3 - 28C series EEPROM

The commands I am running:

1. minicom
2. w (I have also tried w0
3. esc-z
4. s
5. down, down (select xmodem)
6. enter
7. left, left, left, left, left (select Goto)
8. enter
9. (type in directory)
10. enter
11. down, down... (highlight file)
12. space (select file)
13. enter
14. wait (window shows, but no progress indicator. No success or error messages)
15. d
16. enter

The dumped data is not correct

Based on my ability to disable write protection I assume things are wired correctly. I can think of two possible issues:

1. My image is not correct
   • My image is a binary file with no header information. When viewed with xxd the contents are correctly displayed.
2. I am not executing the correct commands
   • I have yet to find any documentation as to how to actually burn an image using TommyPROM, so this is very likely.

Hi there,

Not an issue as such... Can this project use the 74HC595 shift registers as an alternative shift register? I have about 20 of those, but no 74LS164. Thanks :)

Poking, zapping and filling works fine, but when I send a file through Xmodem (minicom), atleast the first page (which has the entire program) is just not written at all, it does fill the entire EEPROM with 0 and put 00 80 at the end, but first page is all 0

If that matters, I made a PCB and CE is always low

And here's the file I'm trying to upload (zipped):
hello.bin.zip

While I can write this through Poking it's just not practical as the program gets bigger

Any idea of what causes this?

I can't unlock my AT28C256 with TommyPROM. I'm using two arduino one, one for the real code and one emulating the two shift register, but thare aren't any problem in reading the eeprom. If I use the unlock command and after the zap command it prompt me a writing error.

Hellom love the project, i am builing one but a have a question,
can it programm the Winbond W27C512?

Hi, I've built the programmer exactly as described, quadruple checked all the connection and loaded the latest version of the code onto my Arduino Nano (this one to be specific), but still the shift registers only output high values, regardless of what I enter into the HardwareVerify program.

OE pins are held low, and SRCLR pins are held high, all as described here and in data sheets - is this something you've seen before? I'm wracking my brain to think what it could be and all I can think is that something in the code is not working

Hi Tom,

I would like to program a couple of 27C040 EPROM's and would like to know if your programmer will work? I see in the code for the 27 series that there's a write function hence why I asked as it's not stated in the readme that it does yet.

Kind Regards, Dan

Hi,
I've assembled the TommyPROM on a breadboard with the 74HCT595 registers. But writing/reading aren't functioning properly, my wiring probably is at fault. I uploaded the HardwareVerify sketch, but in my serial terminal (MobaXTerm) I don't have a CLI (I set the baud rate to 115200). I recieve two '#' and that is it. The standard TommyPROM sketch works as inteded. Screenshots present.

/Terminal with the Hardware Verify Sketch/

/Terminal with the TommyPROM sketch/

I downloaded the V2.2 code to verify the Xmodem fix.
Some new code has been added to support '595 shift registers. I enabled the define, and verified that my hardware was setup as per the revised documentation. Yes I had used D13 as the RCLK pin too. So no wiring changes were needed.
Eeek, it didn't work.

I think the problem is this define in PromAddressDriver.cpp that is used in setAddressRegister():
`// Define masks for the address clk and data lines on PC3..PC5 for direct port control.

#define ADDR_CLK_HI_MASK 0x80`

This was 0x08 in V2.0 of the code, where no define was used. Or am I going mad?

Current code only supports LF as the end of line character. Some terminals default to CR instead, so support either transparently to allow greater compatibility with different terminal software.

Hi Tommy,

I'm trying to build a reader/writer for a 128mbit ROM board that uses a 72 pin SIMM based pinout (essentially, it's two SOP44 64mbit NOR Flash chips in parallel, so it's got 32 data lines and 22 address lines). This is quite a bit bigger than an EEPROM! But I was hoping that since it's fairly simple in scope, that the TommyPROM concept would work with more shift registers.

What I wanted to know, as a fairly green electronics person to someone who is a little more experienced, am I barking up the wrong tree here, or do you think this is possible?

Thanks,
AJ.

Hi,
I'm having problems with reliability writing to an atmel AT28C256 eeprom

About 5% of the time I can write, 95% of the time, it will fail at various points, usually below 50% but not at a consistent packet number.

Reading is fine and writing to the a xicom 28c512 is fine (i've moved the address lines to the right point for the 256).

I notice in your pcitures of your board you have some capacitors - are these to improve reliability? If so, which pins are they on?

Thanks

Thanks for the EEPROM programmer design and code Tom. After a couple of hours debugging my vero board implementation it seems to be working quite nicely.

Sometimes I only need to write a few bytes to an EEPROM, usually to fix a bug in a subroutine, so I wrote a new command POKE, PSSSS BB BB BB.. up to BLOCK_SIZE bytes. I mostly copied existing code from the fillBlock Command but I am struggling with how to test for the end of the command line. Using while ((*byteString != 0) && (byteCtr < 32)) cuts off the last argument.

I increased the size of the CLI command line buffer to accomodate this (132 characters) and added a switch to the CLI processing routine.

void pokeBytes(char *& byteString)
{
uint32_t val;
uint32_t start;
int byteCtr;

enum { BLOCK_SIZE = 32 };
byte data[BLOCK_SIZE];

//first value returned is the starting address
start = getHex32(byteString, 0);

val = getHex32(byteString, 0);
byteCtr = 0;

while ((*byteString != 0) && (byteCtr < BLOCK_SIZE))
{
data[byteCtr++] = val;
val = getHex32(byteString, 0);
}

if (!prom.writeData(data, byteCtr, start))
{
cmdStatus.error("Write failed");
return;
}

delay(100);
for (int ix = 0; ix < byteCtr ; ix++)
{
byte val = prom.readData(start + ix);
if (val != data[ix])
{
cmdStatus.error("Verify failed");
cmdStatus.setValueHex(0, "addr", start + ix);
cmdStatus.setValueHex(1, "read", val);
cmdStatus.setValueHex(2, "expected", data[ix]);
return;
}
}
cmdStatus.info("Poke successful");
}

F 000 050 FF

D 00 050

00000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
00010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
00020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
00030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
00040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
00050: ff .

P0000 01 4f 12 06 4c 24 20 0f 00 0c 08 60 72 42 30 38

POKEing bytes into memory

INFO: Poke successful

D 000 050

00000: 01 4f 12 06 4c 24 20 0f 00 0c 08 60 72 42 30 ff .O..L$ . ...`rB0.
00010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
00020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
00030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
00040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ........ ........
00050: ff

It would be nice to have an on-screen confirmation to say that is has run a successful multi-pass check and that it is OK.
(Currently, it just drops the cursor on to a new line).

Thank you so much for the project - I've successfully built the device and it works . . . ish.
Stuggling to read 27128 chips . . . bizarre problem for another time . . .

I built the TommyPROM project with the intention of archiving a pile of ~35+ year old EPROMs. I assumed that the Xmodem transfer works with some terminal program, probably on a Windows or Mac Operating System. But the transfer always failed on Ubuntu Linux using minicom (which invokes a unix program named rx to receive the file). Here is an explanation of the fault and a simple fix.

An Xmodem protocol explanation can be found by searching for e.g. "MIT XModem protocol with CRC". It is a character based protocol easily as old as my EPROMs!

The TommyPROM Xmodem.cpp source file has a function called SendFile() that controls the transfer. After the last packet is sent, it sends an EOT character and terminates with success, not waiting for the final ACK from the receiver. Two things now happen:

1. Control returns to the main loop() which finds there is a command status message to send. It immediately sends it (INFO: blah) to the Xmodem receiver, which looks like further packet characters to "rx". "rx" then chokes and starts to NAK and CANcel. Bad.
2. The positive ACK character is received by the main command loop and this causes the next user command in TommyPROM to fail (because the ACK character is in the command buffer) Worse, the ACK it has been echoed back to the Xmodem receiver. Phew!

A suggested fix is simple. Consume and process the character returned from the EOT packet in the SendFile() function before returning viz
`
Serial.write(XMDM_EOT);

// Consume the expected ACK response
rxChar = GetChar(5000);
if (rxChar != XMDM_ACK)
{
cmdStatus.error("Expected XModem ACK to EOT, but received:");
cmdStatus.setValueDec(0, "char", rxChar);
return false;
}
return true;
}
`
The command status message (INFO: blah) is still lost unless the terminal program is very quick to revert. But it is displayed on the next menu refresh.

Thanks again Tom for putting this all together. I sense success is close for me.

Greetings, Tom. Would you consider modifying the hardware by replacing the serial-to-parallel 74HC164 ICs with a pair of cascaded 8-bit parallel 74HC574 ICs? The change would free up a few pins on the Nano and setting the address lines should be much faster. One 'downside' is that breadboard or PCB routing would be a little bit more involved.

Setting the address lines is accomplished by writing two bytes to the '574s. Note that the /OE pin is maintained high and the /CE pin should be high when setting the address latches. Set the data lines with the high address byte, strobe the /OE pin low then high, set data lines with low address byte, strobe the /OE pin low then high. After that, you can take the /OE pin low when required in order to read a byte from the ROM, however if you take it from low to high you'll corrupt the address latches.

Cheerful regards, Mike, K8LH (Michigan, USA)

Thank you so much for designing this and putting it on GitHub - just built one to program a 28C512 to update a 486 motherboard bios.

There is a minor error in the schematic diagrams - the logic shifters dont have their ground and vccs connected - for me at least, not connecting these resulted in no read/writes.

Thanks again!

Hi Tom,

Is there anything that can be stripped out to allow this sketch to fit into the Nano 168 (rather than the 328)? Or would that be unachievable? I only need to program the 28C256 chip, but it looks like you only load code for the selected chip anyway.

I'm not sure if there are any other reasons why this would not run on a Nano 168, other than memory size.

Steve

Hi Tom, I wonder if you can offer any advice on my issue.

I'm on a Mac. I have installed lrzsz using Brew. I then use the screen command to connect to the TommyPROM. Press w and enter, then press ctrl+A, then type
:exec !! lsx -b -X /path/to/my/file

It seems to start sending, fails on the first few bytes, then seems to successfully send until it reaches 65536.

What I think is happening is that the first few bytes are my small test program, and the remaining bytes are probably all zeros. I wonder if the checksum is failing for the bytes containing my program, but succeeding for all the zeros. Just a guess.

I get a success message at the end, but the result is a chip full of zeros.

I have tried with the XMODEM_CRC_PROTOCOL commented out/in and seem to get the same results.

Any advice is appreciated.

w
Send the image file using XMODEM CRC
CCCCSending /Users/steve/Downloads/test.z80.bin, 512 blocks: Give your local XMODEM receive command now.
Xmodem sectors/kbytes sent: 0/ 0kRetry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Bytes Sent: 65536 BPS:2650

Transfer complete

The address shift registers are not working when using 74LS595 hardware. See this thread: https://www.reddit.com/r/beneater/comments/j83zu1/using_tommyprom_28c256/

The fix for #19 has broken TeraTerm support. It seems that TeraTerm does not like to send files when TommyPROM asks for checksum mode instead of CRC mode. The TeraTerm dialog shows that it is using checksum mode, but the checksum calculation on TommyPROM fails. Will need more investigation to determine the failure point.

In the meantime, the default file transfer prototol is now back to XModem-CRC for TeraTerm compatibility. Linux users will need to comment out the CRC #define at the top of XModem.cpp to use checksum mode instead.

Discussion here:
https://www.reddit.com/r/beneater/comments/jsf1hk/tommyprom_xmodem_sendwrite_problem/

There is 5.5v marked on the Nano, what is VCC then? I'm thinking on getting two little charge pump boards for the 5.5 an 25.5 volts
no?

here is a video I made -----> https://youtu.be/NpmLo4B8duw

Thanks in advance!

Having rebuilt this using 164s instead of 595s it works in serial term zap test etc. Obviously I can't send a file that way though.

TeraTerm connects and shows the > but pressing enter does not cause menu to display it just sits there waiting. No other command works either. I've checked settings in Tera Term and can't see any issues correct baud, stop bits & parity etc.

Any ideas what I might be missing?

Kindly please extend the code to cover Atmel 29C020 devices

Thx!
Chris

Instructions say to uncomment #define SHIFT_REGISTER_IS_595 in Configure.h
I do not see this in Comfigure.h nor do I quite see how it requires this when I look at. The adrressing code ( it appears that the 595 rclock is toggled whenever an address has been shifted. However my attempt of building programmer does not seem to be updating the address (writes and reads one value to entire room.
Thanks for any help.

Some Atmel AT28C256 chips are showing random write failures. This can be seen using the W command to send XModem data or just by filling a large memory area with the F command. The failures are not consistent - the chip may fail once and then write the same location correctly on the next attempt. Observed with multiple AT28C256-12PU chips with a date code of 1747 while another set of chips with date code 1636 showed no problems. Also see this reddit thread: https://www.reddit.com/r/beneater/comments/j8lvq8/cannot_get_tommyprom_to_work/?utm_source=share&utm_medium=web2x&context=3

I've been using 74HC595s using wiring based on Ben Eater's EEPROM breadboard project and the fork of your project from leomil72. When I run the Zap test I get the following error

ERROR: Verify failed addr=0x0 read=0x33 expected=0x41

It looks like very address is getting set to 0x33 (the last value in the test data)

Any suggestions as to where to look to figure out what I've messed up? Thanks

Hi,
Was wondering if anyone has tried this chip? I have added a line to TommyPROM.ino

PromDevice28C  prom(2 * 1024L, 0, 10, true);  // 28C16 with no page writes

However I'm not having any luck writing to it:

>u
Writing the unlock code to disable Software Write Protect mode: OK
>p 0 00
INFO: Poke successful
>d 0 0f
00000: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ........ ........ 
>p 0 ff
ERROR: Write failed
>d 0 0f
00000: 1c 1c 1c 1c  1c 1c 1c 1c  1c 1c 1c 1c  1c 1c 1c 1c  ........ ........ 

I'm talking to it using minicom on Linux.

(I have assembled TommyPROM on a PCB btw.)

Any help appreciated!
Steve

The background to this is that I have built the TommyPROM hardware using 74HC595 shift registers. So with both hardware and software changes a bit of testing is needed! As a result I have discovered that the Troubleshooting documentation is misleading:

1. Testing the address lines - the table shows the commands A0, A1 etc to setup the address latches. But the correct commands are A000, A0001 etc. So all four hex digits are required as the program menu shows. See below for some examples of this.
2. Data test commands - look like they have the same problem. Always use 2 hex digits.
3. Testing the control lines - the 4th line in the table has a typo? "Cd" should read "Od".

To illustrate the address line testing commands I added a print statement to the 'a' command processing code viz
`case 'a':

    if (hexDigit(line[1]) <= 15)
    {
        w = hexWord(line + 1);
        printWord( w );
        Serial.println();
        Serial.println( w, BIN );
        prom.setAddress(w);
    }
    else
        cmdError = true;
    break;`

Now the difference between A0 and A000, and A400 and A0400 can be seen.
`#a0
ffff
1111111111111111

#a0000
0000
0

#a400
40ff
100000011111111

#a0400
0400
10000000000

#`

IMHO the software bug (buffer over-read) doesn't need to be fixed. It is hardware testing code after all. Just adjust the documentation. It will have the side effect of reducing the confusion between A0 the command and A0 the 0th address line, and D0 the command and D0 the 0th data line.

Thanks for taking the time to design and document this project. It's encouraging to see proof that it will work in the end ;-)

Greetings!

I have been trying very hard to port your code the newer Nano version but I am not sure what to use in place of port variables, which are not compatible with this AVR version and official documentation or forum resources are quite sparse.

I tried substituting the following:

• PORTB as PORTB.OUT and PORTB.IN such as
  • PORTB = (PORTB & 0xfc) | (data >> 6); becomes PORTB.OUT = (PORTB.IN & 0xfc) | (data >> 6);
• PINB as PB
• DDRB as PORTB.DIR thus
  • DDRB |= 0x03; is rewritten as PORTB.DIR |= 0x03;

... and various other combinations.

For example, using the Dff or A7ff commands, no data or address lines change state, I suspect due to above being incorrect. I would be exceptionally grateful if such support were to be released and tested by the developer as my experience with Arduino is limited.