Writing to a parallel EEPROM

QuinnDunki · Post by **QuinnDunki** » Mon Jan 16, 2012 5:42 pm

Hey everyone! Garth sent me over here, and indicated you folks might be able to help me with something.

I've hit a wall on my "Veronica" 6502 project ( http://quinndunki.com/blondihacks/?p=780 ) , and no amount of googling or researching or experimenting is helping anymore.

I have an Atmel AT28C256 32k x 8 parallel EEPROM (data sheet: http://www.jameco.com/Jameco/Products/P ... 4843AT.pdf ). I am trying to write to it, but nothing I do seems to work. The datasheet says it works just like an SRAM, but my circuit ( http://quinndunki.com/blondihacks/wp-co ... vB_Sch.jpg ) which writes correctly to SRAMs has no effect on the EEPROM.

Let's reduce it to the simplest possible case. For example:

1) Hook up Vcc and ground on the EEPROM
2) Tie all address and data lines to ground
3) Tie /CE low, /OE high, and /WE high
4) Briefly touch /WE to low, then back to high.

I expect this to write 0x00 to address 0x0000. On an SRAM, that is what happens with this exact test. On the EEPROM, I get 0xFF (the factory default value) back. I've tried everything I can think of, but I cannot get any byte to write anywhere into this thing. I've tried four different chips, thinking one might be bad. I also tried disabling the Software Write Lock, per the datasheet, even though it is supposed to be disabled from the factory. All four chips were purchased new from Jameco.

The above breadboard test works on an SRAM just fine, as does my dedicated writing circuit (linked to above). So I'm skeptical of the datasheet's claim that the EEPROM is written to the same way. I'm intentionally avoiding the page-write mode by only writing a single byte, to eliminate variables. I've scoured the data sheet, trying to find some trick that I've missed, but I can't see anything wrong. I've gone through the timing diagrams with a fine toothed comb, and spent hours on the logic analyzer, but can't find anything I'm doing differently from what the datasheet specifies.

Any and all suggestions would be much appreciated. I'm completely out of ideas on what might be wrong. It must be something silly, because the datasheet makes it sound very simple to use this thing. I have a couple of new chips en route from another source, but that's a long shot. I can't believe all four of the ones I got are bad?

- Quinn

Nightmaretony · Post by **Nightmaretony** » Mon Jan 16, 2012 6:11 pm

One thing that may help out, look for some Atari arcade game schematics such as Tetris which was 6502 based and used an EEPROM for data storage. So it definitely CAN be done.

QuinnDunki · Post by **QuinnDunki** » Mon Jan 16, 2012 6:23 pm

Nightmaretony wrote:

One thing that may help out, look for some Atari arcade game schematics such as Tetris which was 6502 based and used an EEPROM for data storage. So it definitely CAN be done.

Thanks, that's an interesting idea!

Just in case it wasn't clear, the 6502 isn't doing the actual writing. I'm just using an EEPROM as normal system ROM on my homebrew computer. I'm trying separately to write to the chip, since EEPROM programmers are pretty spendy, and it really seems like a simple thing to do yourself. At least, so I thought...

8BIT · Post by **8BIT** » Mon Jan 16, 2012 6:49 pm

The data sheet says the software data protection comes disabled. I have had at least one eeprom (can't remember the manufactureer) come with the protection enabled.

Try to execute the software data protection disable sequence, then do some test writes. If that doesn't work, we may need to look at the code you are using to perform the writes.

I have successfully programmed several 28C256 eeproms in-system on my SBC-2, so I know it can be done. There are some write timing parameters that need to be followed though.

Daryl

QuinnDunki · Post by **QuinnDunki** » Mon Jan 16, 2012 6:57 pm

8BIT wrote:

The data sheet says the software data protection comes disabled. I have had at least one eeprom (can't remember the manufactureer) come with the protection enabled.

Yah, that's kinda what I'm afraid of. Could I have four chips all with it enabled? Perhaps. I tried writing the unlock sequence, but I'm not 100% certain that I did it correctly. The ATTiny uC that I'm using to write sequences is right on the edge of being able to push bits out fast enough for the 150uS page-write window. If I'm reading my scope correctly, it looks like I have ~120uS between bytes. The datasheet says the unlock sequence must conform to the page-write timing, so it's dangerously close.

I can try upping the clock speed on my writing circuit to make really sure I'm within the page-write window.

I also have two more chips coming in, from a different supplier and a different brand (second source). If the software locks are enabled by default on my current chips, these may be different. *fingers crossed*

BigEd · Post by **BigEd** » Mon Jan 16, 2012 10:06 pm

One thing to note: you're supposed to read back the complement of the last byte you wrote, until the internal read operation is finished. Did you wait long enough (10milliseconds)? (Put another way: if you write any other value, do you get back the complement?)

Edit: oops, that's only bit 7, so that would be obvious. Forget that then.

(Oh, and welcome!)

Cheers
Ed

QuinnDunki · Post by **QuinnDunki** » Mon Jan 16, 2012 10:14 pm

BigEd wrote:

One thing to note: you're supposed to read back the complement of the last byte you wrote, until the internal read operation is finished. Did you wait long enough (10milliseconds)? (Put another way: if you write any other value, do you get back the complement?)

(Oh, and welcome!)

Cheers
Ed

Thanks! I feel welcome already. People have been most helpful.

The data polling thing is curious to me- I assume you only have to do it if you want to write another byte as soon as possible, correct? If I'm only writing a single byte, it doesn't matter? Or if I'm writing multiple bytes, as long as I wait >5 ms between them, it should be okay?

The read-back-after-you-write thing seems like an optimization tool if you want to build the fastest possible EEPROM programmer. For now, I'd settle for getting a single byte to write at all.

I did try examining the IO7 bit immediately following my write (using a logic analyzer), and it does report the complementary bit for about 1ms following the /WE pulse. That seems like what should happen for a normal write, but then the value I wrote seems to be ignored. A read of the same address ~10ms later still shows the erased state of 0xFF.

I haven't tried reading a full byte back immediately after writing, because my uC doesn't have enough pins for that. I hope that isn't somehow needed for a successful write.

BigEd · Post by **BigEd** » Tue Jan 17, 2012 8:50 am

I should add a disclaimer: I've only had a look at the datasheet. 8Bit has actually used the devices! It seems most likely that software protection is the problem - the device accepts the writes and goes through a write action but doesn't commit the data. (I wonder if the parts are in fact not new?)

It's a pity, if true, that page mode timing is needed to unlock - the datasheet suggests it - because it means you need a faster and more complex system to get started. (Your bootstrapping technology reminds me of a friend's setup which uses i2c and is similarly speed-limited.)

Could you perhaps put the short sequence of data and addresses into a set of RAMs and pump them in parallel into an EEPROM to do the unlock? Actually, both the addresses and data are mostly A's and 5's, so maybe only a few distinct inputs are needed, with a fair amount of fanout.

Code: Select all

5555 AA
2AAA 55
5555 80
5555 AA
2AAA 55
5555 20

(As far as I can see, during a write operation other reads and writes won't be honoured. Again, 8Bit might be able to be more definitive.)

Cheers
Ed

8BIT · Post by **8BIT** » Tue Jan 17, 2012 1:16 pm

I have in the past offered this to anyone:

You are welcome to send the chips to me and I can test them on my programmer, unlock them if needed, program and return them. All I ask is you cover the return postage.

When and if desired, just pm me and I can provide shipping info.

Daryl

8BIT · Post by **8BIT** » Tue Jan 17, 2012 2:57 pm

Here's another thought, I build this after I finished my sbc-2.

http://sbc.rictor.org/io/28256.html

It is designed to connect to a 6522 but it originally was connected to my PC's parallel port. That is how the first EEPROM for the SBC-2 was programmed.

Don't know if you have a PC that still has a parallel port, but this could be a solution. One thing is you may want to do is buffer the data lines with a 74hc573 if you use the parallel port. I also remember having trouble using the strobe signal reliably, and ended up using one of the other handshake pins for the clocking.

This will also require an OS that will allow you to access the parallel port from software. I used windows 95 back then but I may have booted to a DOS floppy disk. I used QuickBasic to do the actual port communication with. I can dig up those files if you are interested. otherwise, the 65c02 code to do programming is in the link above. I can also dig up the unlock code if you would like it.

Daryl

QuinnDunki · Post by **QuinnDunki** » Tue Jan 17, 2012 3:32 pm

Great suggestions, everyone! I think my next step (while waiting for additional chips) is to try and get an ATTiny to bang bits fast enough to meet the page-write spec, and thus write the unlock sequence. I've tried doing it byte-by-byte, both by hand and via the uC, but it seemed to have no effect. The data sheet says something along the lines of "software commands must meet the timing requirements of page-write mode". We'll see what I can do.

Sadly I don't have a parallel port on any anything. Shame, because there's a lot of simple EEPROM writing circuits floating around that use it. Part of the problem with this process is that the inexpensive programmers often rely on old PC hardware and software.

This is frustrating, because it should be such a simple thing!

zx80nut · Post by **zx80nut** » Tue Jan 17, 2012 4:01 pm

If these are new devices then the software protection is not the issue.
The datasheet page 4 states...

"The SDP feature may be enabled or disabled by the user; the AT28C256 is
shipped from Atmel with SDP disabled."

I've used smaller ones (2864) in-circuit and treated them exactly the same as SRAMS with no issues.
Check Vcc is clean, as below 3.8V (I think) the write disable kicks-in.

QuinnDunki · Post by **QuinnDunki** » Tue Jan 17, 2012 4:06 pm

zx80nut wrote:

If these are new devices then the software protection is not the issue.
The datasheet page 4 states...

"The SDP feature may be enabled or disabled by the user; the AT28C256 is
shipped from Atmel with SDP disabled."

In theory, yep, I'm right there with you. Attempting to disable SDP is indeed the act of last-chance desperation that it appears to be.

This idea was bolstered by 8BIT's observation that he has in fact seen them come from the factory with SDP enabled, on occasion.

QuinnDunki · Post by **QuinnDunki** » Fri Jan 20, 2012 3:02 am

Hey everyone- just thought I'd update this to close out the thread. After many hours, I finally got this working. It turns out, in fact, all four of the EEPROMs in the first batch I purchased were bad. Two new ones purchased from another source worked perfectly with my existing circuits. Just goes to show, sometimes the thing you can't believe is the problem is the problem.

Thanks for everyone's help!

The final in-system programmer that I've built will be posted on my site shortly, so stay tuned if you're interested:
http://www.quinndunki.com/blondihacks

Nightmaretony · Post by **Nightmaretony** » Mon Jan 23, 2012 6:05 pm

The thread will never close as long as new ideas and techniques and help for people can still be added :d