6502.org

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.

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.

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.

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…)

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?

Your Java GUI connected to your sketch fails in a much better way:
(It falsely claims success, but at least doesn't crash, and it does indicate the errors)

From a serial session, I see this:
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.

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.

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.

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:
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:
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)

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:
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)

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.

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...

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