28Cxxx EEPROM Programmer

[pda]

Thanks for all the awesome work.

I'm hoping for a tip on troubleshooting my breadboard build of this.

The data bus appears to work; I can hardwire a byte and see it repeated infinitely for reads.
The address bus appears to work; I added a serial command to manually set an address, and inspect it with LEDs.
Reads appear to work, hard wired byte reads correctly, but I only have brand new 28C64 EEPROMs; they both read as all 0xFF. Not sure if that's normal/correct.
I've also slowed the baud on both ends in case that helps.

Writes are the problem; any attempt to Write or Erase lock up the Java client indefinitely.
I've tried a few versions of the client and the RXTX lib. I'm using Mac OS 10.9.

I've also tried tying the data bus to the low byte of the address bus, expecting to see `0x00 0x01 0x02 0x03 …` on reads, but the actual read data seems corrupt.

My next step will be to initiate some writes via serial monitor, and see if I get a meaningful response.

In the meantime, does this sound like an explainable problem to anybody?
Or any bright ideas for debugging?

Thanks.

[rpress]

UnaClocker wrote:

I sold out, all 10 of the boards I had made. I created a new board with rpress's revisions and just sent that off to the fab. I'll have to order some more eeproms to confirm the new design works. And rpress, I'll send you one of the new boards when they get here.

That would be great, thanks! I should have enough parts to build another, it will be nice to have a backup. I've programmed a couple dozen chips, it's been great.

pda wrote:

Writes are the problem; any attempt to Write or Erase lock up the Java client indefinitely.

This is probably because the Arduino is waiting for the write to complete. A timeout would be nice but there isn't one. Because your reads aren't working right, the writes will hang. So figure out why the reads don't work first.

What kind of Arduino are you using?

[pda]

rpress wrote:

pda wrote:

Writes are the problem; any attempt to Write or Erase lock up the Java client indefinitely.

This is probably because the Arduino is waiting for the write to complete. A timeout would be nice but there isn't one. Because your reads aren't working right, the writes will hang. So figure out why the reads don't work first.

What kind of Arduino are you using?

I'm using an ATmega328p in a Uno-compatible board.

There's certainly something amiss with my address bus, after all.
I've added an address-setting command, e.g. to set only the high byte pins: `A,FF00`.
It's showing strange behavior... I'll look into my '595 wiring.
I'll also send a GitHub pull-request for the `A` command; it's useful for pin and shift-register byte order debugging.

[pda]

Wait ... mkeller's code seems to (despite the comments) shift the low byte, then the high byte:
https://github.com/mkeller0815/MEEPROMM ... #L140-L143
I think that's contrary to the 74HC595 wiring at http://www.ichbinzustaendig.de/dev/meeprommer-en

But your (rpress) code seems to correctly shift the high byte then the low byte:
https://github.com/presslab-us/MEEPROMM ... #L249-L254

So the 74HC595 ordering (or address bus byte order) differs between the two versions?
Or am I reading something wrong?

(It would explain why my byte order seemed correct, and then later incorrect, as I switched versions…)

[rpress]

That's strange. I didn't specifically change the address byte order; I am using the hardware from UnaClocker which I assume is from that schematic you linked. Maybe it's a bug in the original version?

Oh, also I noticed I did implement a timeout for byte writes in the Arduino. Was the Java freezing up when using my sketch?

[pda]

rpress wrote:

Oh, also I noticed I did implement a timeout for byte writes in the Arduino. Was the Java freezing up when using my sketch?

Your Java GUI connected to your sketch fails in a much better way:

Code: Select all

sending command.
wrote data from 0x0000 to 0x03FF
Error: Communication timeout
data sent.
wrote 8192 bytes from 0x0000 to 0x1FFF in -1.38516544E9 seconds

(It falsely claims success, but at least doesn't crash, and it does indicate the errors)

From a serial session, I see this:

Code: Select all

<- V<newline>
-> MEEPROMMER $Revision: 1.4 $ $Date: July 31st, 2013 1:00pm $, CMD:A,R,r,w,W,V,C,E,P,p
<- w,0000,0004<newline>
<- test<newline>
   (three full seconds pass)
-> %
<- R,0000,0004
-> 0x0000 : FF FF FF FF 
-> %

Also, repeatedly calling set_address_bus(value) sometimes works, other times sets the bus to 0x0000.

It's probably time to pull it apart and assemble it with fresh wires / breadboard!

Thanks for your help, rpress.

[pda]

Argh!
I pulled out everything except the low-byte shift register, and had a sketch looping set_address_bus(0xFFFF).
Instead of staying on constantly, it slowly and randomly blinked on and off (~50% duty cycle).
Swapped the 575, same problem.
Swapped all the wires. Same problem.
Moved the chip eight pins down the breadboard - fixed!

That breadboard owes me quite a few hours of my life back, and will be terminated accordingly.

[rpress]

pda wrote:

(It falsely claims success, but at least doesn't crash, and it does indicate the errors)

Ah, that should probably be fixed, although I suppose the verify will fail at some point. If you feel up to fixing that, feel free by all means.

Glad you got your hardware sorted.

[pda]

Address bus and data bus are looking good now.
Here's a read with the data bus tied to the low-byte of the address bus:

Code: Select all

0x0000  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 
... (continues to FF then loops)

Unfortunately I still get timeouts on write, and both EEPROMs I have read as entirely 0xFF.
Sometimes the write appears to get into the second 1024 byte block, but the chip still reads as all 0xFF afterwards:

Code: Select all

sending command.
wrote data from 0x0000 to 0x03FF
wrote data from 0x0400 to 0x07FF
Error: Communication timeout

I'm thinking the EEPROMs might be dead.
Maybe I fried them during some incorrect wiring.
Or maybe they were dead on arrival like at http://quinndunki.com/blondihacks/?p=805 (also from Jameco)

[rpress]

Did you confirm the /CE, /OE, and /WE signals are working?

[pda]

rpress wrote:

Did you confirm the /CE, /OE, and /WE signals are working?

Good idea - I had checked the wiring, but not the signals.
However, they're working fine, according to some LEDs and this code:

Code: Select all

  while (true) {
    set_ce(HIGH); delay(500);
    set_oe(HIGH); delay(500);
    set_we(HIGH); delay(500);
    set_ce(LOW);  delay(500);
    set_oe(LOW);  delay(500);
    set_we(LOW);  delay(500);
  }

The last thing I'll eliminate is the serial connection, by hard-coding some data in the sketch, and writing it on boot.

Edit: (I'm pretty suspicious about the RXTX library and its native interface under Mac OS 10.9 Mavericks. Various versions are crashy or don't work. The ones that do work prevent Arduino 1.0.x from starting, although Arduino 1.5.x works. But it crashes when closing the serial monitor. I'm using RXTX-2.2pre2)

[pda]

No joy with the EEPROMs.
Attempted writing a 1024 byte block at Arduino startup. Still times out on data polling.
I replaced the data polling with 10ms delay, so that all byte write attempts were made.
It still reads back as 0xFF.

BUT - it works with SRAM.
I only had those two EEPROMs, but I've also got a batch of 10 brand new 32K 10ns SRAM chips which are very nearly pin compatible.
I adjusted the wiring, replaced the EEPROM with SRAM, and it works perfectly. I can read and write images etc.

So I'm pretty sure those EEPROMs are dead.
I wonder if that's a normal failure-mode; to always read as 0xFF but to refuse writes.

[rpress]

Maybe a problem with VCC? Check the datasheet for your chip (different mfgs have different tolerances) and check your actual VCC. Also make sure you have sufficient decoupling caps.

Programming an (E)EPROM takes a high voltage, the 28C chips generate this internally. So yeah, that part could have failed...

[Dr Jefyll]

pda wrote:

So I'm pretty sure those EEPROMs are dead.

Just a reminder -- despite similarities in pinout, EEPROMs and RAMs are not drop-in replacements for one another. If you haven't already, be sure to read the EEPROM data sheet thoroughly... just in case you've overlooked a little detail like this.

-- Jeff

[GARTHWILSON]

From time to time someone on the forum is sure the new parts they just got are dead. I have never had defective ICs from a supplier. Never. I started buying ICs in 1975 in my hobby, and 1985 in my work. You do of course have to be careful about static handling precautions, and I see people get pretty careless about that. Make sure you're going by the data sheet, and then make some measurements before putting the new part in the socket. Check power & ground first, then feed it the intended signals and make sure they show up at the socket pins correctly, etc..