Writing to a parallel EEPROM - Page 1
Forum section: electronics / projects

author: QuinnDunki
author_rank: Contributor
timestamp: January 14, 2012, 06:46:14 pm
content: Hey everyone!I've hit a wall on my Veronica 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/ProdDS/74843AT.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-content/uploads/2012/01/ROMEmulator_RevB_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 EEPROM2) Tie all address and data lines to ground3) Tie /CE low, /OE high, and /WE high4) 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 4-step test works on an SRAM just fine, 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.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

author: Unknown
author_rank: Unknown
timestamp: January 14, 2012, 07:21:54 pm
content: Since you're using an ATTiny13 with shift registers, you probably don't have to worry about meeting <= 100ns setup and hold times. Do you wait for at least tWCbefore reading? Before the write cycle is finished, it should return the complement of the data, which would also be 0xff. This is the major difference between SRAM and EEPROM that comes to mind.

author: QuinnDunki
author_rank: Contributor
timestamp: January 14, 2012, 07:32:38 pm
content: Thanks for the reply!Yah, writing a single byte at a time with the little ATTiny13, it's no problem meeting the minimum delay requirements.For now though, I'm only focusing on the manual four-step test described. I'm trying to write a single byte by hand using a breadboard and moving the wires by hand. It's the simplest possible test I can think of, and it works great for the SRAM.I've tried writing different bytes to different locations, and nothing seems to change. I can read bytes just fine, but it's always 0xff. The writes appear to be ignored.

author: Unknown
author_rank: Unknown
timestamp: January 14, 2012, 07:55:24 pm
content: Quote from: QuinnDunki on January 14, 2012, 07:32:38 pmThe only parameter you have to pay attention to is tWC, which is in the order of ms, and tBLCfor page writes.Quote from: QuinnDunki on January 14, 2012, 07:32:38 pmWhat about contact bounce or bad breadboard contacts resulting in timing violations (either setup and hold or minimum rise time)? Do you have access to an oscilloscope or logic analyzer? In that case I would verify signals and timings by probing directly on the pins. Programming an uC to do the write will be more repeatable and easier to probe, although I would skip the shift register for now and connect three pins directly to /OE, /CE and /WE. This should create nice, clean edges.

author: QuinnDunki
author_rank: Contributor
timestamp: January 14, 2012, 08:12:04 pm
content: Quote from: alm on January 14, 2012, 07:55:24 pmThere's surely some bounce when the wires are connected/disconnected, but it would settle down. This test it so simple- the only connection moving is /WE, and while I'm sure the process is a bit noisy, as long as there's a falling edge, a long enough pause, and a rising edge, I figure it should be fine. At worst, perhaps the byte will get written more than once.In any case, I've also tested the EEPROM and SRAM with my programming circuit, and have studied it on the logic analyzer. I'm quite confident the signals are good there. Since my circuit and this simple test both work 100% with the SRAM, would the EEPROM really be so different?I feel like there must be some trick preventing the writes from occurring, like some sort of protection lock or something.I appreciate your help! All ideas are on the table at this point.

author: Unknown
author_rank: Unknown
timestamp: January 14, 2012, 08:28:33 pm
content: There's obviously the software protection feature that may have been accidentally enabled (though you'd be really unlucky to subsequently hit those specific addresses). If you're driving both the SRAM and EEPROM out of spec (eg. way too slow edges, timing violations, noise, whatever), they may respond differently. Just because the SRAM worked does not prove you were within its specs.Can you verify that the write operation is taking place by either polling (you'll need to write something other than 0x00) or toggling? It's somewhat difficult to do this manually within a few ms, so it would require a uC to perform the write. If the write operation is received, it should by in write state for a few ms or so, even if protection is enabled and the write is ignored.

author: QuinnDunki
author_rank: Contributor
timestamp: January 14, 2012, 08:44:33 pm
content: Quote from: alm on January 14, 2012, 08:28:33 pmGood point! For what it's worth, here's the values at the EEPROM's data (D0-D7) and /WE pins (D10). The write pulse is about 1uS long, and the data and address are present about 1uS before the pulse (and are held for well past the rising edge of /WE). These signals are generated by a uC, so I hope they're within spec for rise times and such, but I'm assuming nothing at this point.http://quinndunki.com/blondihacks/wp-content/uploads/2012/01/IMG_1016.jpgQuote from: alm on January 14, 2012, 08:28:33 pmThat's a good idea. I'll write some code for a uC to run the pins directly, and see what the polling says after the write attempt.

author: Rufus
author_rank: Super Contributor
timestamp: January 14, 2012, 08:49:03 pm
content: Quote from: QuinnDunki on January 14, 2012, 08:12:04 pmIf you are taking dumb suggestions... your VCC is actually 5v, decoupled and glitch free?

author: QuinnDunki
author_rank: Contributor
timestamp: January 14, 2012, 08:50:40 pm
content: Quote from: Rufus on January 14, 2012, 08:49:03 pmHeh, yep, it sure is. Regulated, decoupled, the works. Never hurts to check though.

author: Unknown
author_rank: Unknown
timestamp: January 14, 2012, 09:12:11 pm
content: Quote from: QuinnDunki on January 14, 2012, 08:44:33 pmSignals look fine to me, assuming /OE is tied high and /CE low. The /WE pulse looks shorter than 1us, but tWPis 100ns, and you'd be hard pressed to violate that with a ~10 MHz(?) ATtiny. I would also probe /WE with an analog channel too see if there's anything that doesn't belong there, like noise, ringing or whatever. Keep in mind that the edge rate may be close to the rise time of your scope (about 14ns based on the stated bandwidth).

author: QuinnDunki
author_rank: Contributor
timestamp: January 14, 2012, 09:19:24 pm
content: Quote from: alm on January 14, 2012, 09:12:11 pmYep, /OE high and /CE low. And yah, the uC is 8Mhz max, and I think I may even have the clock divider on, so tWPshould be no problem. The /WE pulse has an explicit 1 uS delay after going low in the uC code just to make sure. The scope's display is pretty low-res, and zoomed out this far, pulse widths are hard to judge. I've zoomed in on it to be sure, though.Quote from: alm on January 14, 2012, 09:12:11 pmInteresting idea- I'll give that a shot.

author: QuinnDunki
author_rank: Contributor
timestamp: January 15, 2012, 12:26:23 am
content: Quote from: alm on January 14, 2012, 08:28:33 pmI just set up a uC to write 0x80 to address 0x0000. Immediately following /WE going high, I enable /OE, in order to do a poll. According to the data sheet, I should see the compliment of my data on IO7during the write cycle.Monitoring all the pins on the logic analyzer, I can see that right after /OE goes low, IO7goes low, which is the compliment of what I had just tried to write. Then, ~1ms later (a nominal write cycle, per the data sheet), IO7goes high again. From there after, all read attempts give 0xFF.So it seems as though the write cycle is proceeding as expected! But then reads return the wrong value! The mystery continues...

author: sonicj
author_rank: Frequent Contributor
timestamp: January 15, 2012, 12:34:47 am
content: i like your blog!dish-o-tron is a classic imo!-sj

author: Unknown
author_rank: Unknown
timestamp: January 15, 2012, 12:41:32 am
content: It'd be worth double checking the data sheet, but I believe the only way that can happen is if the software protect feature is enabled. I think you already tried the 'magic knock' to disable it? Did you try another address in case there's something wrong with that 0x0000 cell? Doing a chip erase might help in case things got in a wonky state (no idea what that state could be). Do you have another IC available for testing? Is there an errata available that states 'single byte writes may not work reliable at even addresses' or something stupid like that? Just trying to keep you busy by thinking of things to try.

author: QuinnDunki
author_rank: Contributor
timestamp: January 15, 2012, 12:47:24 am
content: Quote from: sonicj on January 15, 2012, 12:34:47 amHaha, thanks! The Dish-o-Tron is polarizing. People tell me it's the best idea ever, or the stupidest thing they've ever seen. I suspect there are two distinct lifestyle camps when it comes to dishwasher interaction patterns, and if you're in the wrong camp, Dish-o-Tron makes no sense. I find it to be the most useful thing I've ever built for around the house.

author: QuinnDunki
author_rank: Contributor
timestamp: January 15, 2012, 12:53:41 am
content: Quote from: alm on January 15, 2012, 12:41:32 amYah, I did try the magic knock, although who knows if I did it right. I have four of these chips, and all four seem to ignore writes of any value at any address. I have two more coming from another source, on the off chance that a whole batch of these are bad or something. Seems unlikely, though.Keeping busy trying stuff is good. Sometimes the only way to solve a problem is just to keep banging on it anyway you can think of until you get lucky and stumble on to something.I'm back to being out of ideas for the moment, though.

author: amyk
author_rank: Super Contributor
timestamp: January 16, 2012, 11:34:05 am
content: Are you taking proper ESD precautions?

author: QuinnDunki
author_rank: Contributor
timestamp: January 16, 2012, 03:29:19 pm
content: Quote from: amyk on January 16, 2012, 11:34:05 amI believe so. I work on a grounded anti static mat, and I ground myself before handling chips. The chips are stored in conductive foam. As far as I know, I haven't had any ESD-related failures in any of my chips (EEPROM or otherwise) but I suppose it'll happen sooner or later.

author: QuinnDunki
author_rank: Contributor
timestamp: January 20, 2012, 03:01:28 am
content: 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

author: baljemmett
author_rank: Unknown
timestamp: January 20, 2012, 01:26:07 pm
content: Quote from: QuinnDunki on January 20, 2012, 03:01:28 amUgh, don't you hate that? I remember chasing my tail for a week over some unreliable RS232 comms -- it looked like a timing error, so I tried adding a baud-friendly crystal to an already cramped design, and somehow blew the oscillator driver in the PIC in the process. Once I realised that and replaced the PIC, it still didn't work; it turned out to be a duff MAX232 that was introducing random glitches which were sometimes in just the right place to cause framing errors and dropped bytes. Gah.QuoteDefinitely, I'll be watching your Veronica project with interest. Every time I see a project like that I'm a little bit more tempted to put my "build a CPU out of 74-series logic" project on hold, grab some suitably vintage microprocessor and bring a system up around that instead...

author: Rufus
author_rank: Super Contributor
timestamp: January 20, 2012, 01:44:11 pm
content: Quote from: QuinnDunki on January 20, 2012, 03:01:28 amWhat a pain, do they physically look right?A customer just had a batch of boards shipped from their Chinese manufacturer which he says are pretty much all reporting an EEPROM failure. He says the EEPROM chips (SO8 micowire EEPROM) look like they have been re-marked so they probably built the boards with faulty fake parts (again) <sigh>.

author: QuinnDunki
author_rank: Contributor
timestamp: January 20, 2012, 04:32:22 pm
content: They look pretty normal, yah. No outward sign of being counterfeit, although I've seen some photos of very convincing fake parts, so who knows.

author: Unknown
author_rank: Unknown
timestamp: January 21, 2012, 01:57:10 pm
content: Congratulations on solving this! Guess it's good to know you were not going insane but it was just caused by bad components.