AT28C64B-20PC doesn't write

[alex_6611]

Hello everyone, I've been working on a project lately and needed to program some ROM for it. As I don't have a programmer, I made my own using an Arduino Nano and shift registers, it's almost identical to the one Ben Eater built ([youtube]/watch?v=K88pgWhEb1M). I'm using AT28C64B-20PC chips (http://www.atmel.com/images/doc0270.pdf).

After building and programming it and triple-checking that everything conforms to the datasheet, I tried it. It can set all data/address bits and control lines correctly and when reading, I get the expected 0xff (factory reset chip). However when I try to write, nothing happens. It just retains the 0xff. I tried to set up ~DATA polling and Toggle Bit polling, which both didn't return anything, indicating that my ~WE pulse doesn't even start a write cycle.

I have tried:

• disabling software data protection (see datasheet)
• programming the chip manually with switches (doesn't work either)
• doing a complete chip erase
• checking that all connections are correct and the correct bits are set
• writing to a HM62256 RAM chip instead (pinout is identical), which works
• using another chip (I have 5, works on neither of them)
• playing around with timing and delays

So I decided to ask here, as I am out of ideas. Here's my circuit diagram:
https://puu.sh/yQ4c8/a95a8eca84.png
and here's my code (important bits are the functions at the end):
https://pastebin.com/CbNhUaBE

Thanks in advance for your help.
Alex

 

[kellys_eye]

How is your timing achieved?

Do you poll the EEPROM to check that the write cycle has been completed?

This from the data sheet:

The end of a write cycle can be detected by DATA
POLLING of I/O7. Once the end of a write cycle has been
detected, a new access for a read or write can begin.

 

[alex_6611]

How is your timing achieved?

Do you poll the EEPROM to check that the write cycle has been completed?

This from the data sheet:

The end of a write cycle can be detected by DATA
POLLING of I/O7. Once the end of a write cycle has been
detected, a new access for a read or write can begin.

I wait 10ms between write cycles to make sure that it finished (as stated in the datasheet as max write duration). I also use page write (64 bytes per cycle) for mass writing.

The issue is that when I try ~DATA polling, it doesn't show the described behaviour, and instead just reads a high bit (forever). This indicates that it hasn't even started writing. Reading the byte later also confirms that the write hasn't worked.

 

[kellys_eye]

On a more basic level have you got proper decoupling and supply capacitors on the relevant rails and close to the device?

 

[alex_6611]

Well thanks for pointing that out (I didn't have any), but I tried it with 0.1uF and 2.2uF across the power rails, still doesn't work. Am I missing another place where I should put capacitors?

 

[kellys_eye]

They should be right at the power pins - close as possible - of each device (0.1μF).

 

[alex_6611]

Alright, even with multiple caps around the chips it doesn't work.
So that doesn't seem to be the cause of the issue. Any other ideas?

 

[kellys_eye]

It can only be down to timing now.

I'm not prepared to delve into your coding but unless you can adjust individual parts of it you will require digital monitoring to check the timing waveforms.

 

[alex_6611]

Alright. I'll see if I can experiment a bit more with the timing, as that's the only thing I can do without an oscilloscope (don't have one and currently can't afford a good one). Thanks for your help.

EDIT:
Just FYI, here's the relevant bit of code:

void writeByteRaw(uint16_t addr, byte data) {
  doShift(addr, true); //shifts out address with OE high
  delayMicroseconds(10);
  digitalWrite(WE, LOW);
  for (byte j = 0; j < 8; j++) digitalWrite(j + DATA_OFFSET, bitRead(data, j)); //sets data outputs
  delayMicroseconds(1);
  digitalWrite(WE, HIGH);
}

 

[kellys_eye]

The accuracy of the timing delay seems pretty suspect - do you know what the accuracy really is?

 

[alex_6611]

I can't be sure how long those delays actually are (Arduino docs say that delayMicroseconds is very accurate at 3+ μs), but even if I use (much) longer delays to give it some room, nothing changes.

Also, even if the pulse ends up being longer/shorter than 1μs, it should still fulfill the datasheet requirement of a write pulse length >= 150ns.

 

[alex_6611]

So here's an update, I ordered new chips from a local electronics supplier and tried them. Now it all works as expected. So it seems that I somehow received five defective chips (with very different serial numbers from different factories) in my first order. Ridiculous.

Still, thanks for your ideas.