Maker Pro
Maker Pro

Help programming an EEPROM (AT28C256)

Hello Everyone,

Just a heads up, I am a EE undergrad and pretty new to electronics as a whole. So bear with me if I seem like a super noob ;)

I have spent over 30+ hours on this project already, and it's been fun. Didn't think I would make it this far on my own! This is my final project for my intro to embedded systems class, and I am trying to get it done early. There are no other students currently working on it which makes it hard to ask for help. Anyways I am about 95% done I'd say, but need some help writing/reading from the EEPROM.

Here is the gist of the Project:

The circuit reads a data file with pairs of addresses and data. The addresses/data is stored on the PC and interfaces an EEPROM via an USB I2CIO board. We are to use two 8 bit latches, one for addressees and one for data, that directly connect to the EEPROM. The addresses and data use the same bus so they are time multiplexed to the enable of the latches using a control bit from the 34-Pin IDC connector on USB I2CIO Board.

Once the EEPROM is programmed, a test file containing random pairs the same addresses/data pairs is read from the PC. The address is sent via the A ports to load the corresponding data from the EEPROM at that address.
The data of the test file is sent through the B ports and go straight to an 8bit comparator. The data pins from the EEPROM are also sent to the comparator to prove that the EEPROM was programmed correctly.

All of this is programmed via c++ coding.


Here is a schematic:

2cegk69.jpg



I also have LEDS connected to the DATA pins of the EEPROM for my own debugging.

The part I need help on is writing to the EEPROM. I have tried countless time but it doesn't seem to be programming my address/data pairs. I am pretty confused on how to send my OE WE CE signals to 1st take the address, and then the data.

There are 256 pairs so I have a loop going to write the whole file at once.

Here is a link to the data file

Currently I am sending these signals to with the address latched enabled:

CE-L
WE-L
OE-H

Then I enable the data latch and send:

CE-L
WE-H
OE-H

And this is looped with a small pause in-between each signal change.

This doesn't seem to correctly program the EEPROM. I think I am misunderstanding how to pulse the control signals? Or something to do with timing?

Any help Would be much appreciated.

Thanks for reading!

Marc


 

KrisBlueNZ

Sadly passed away in 2015
The three signals on PC7, PC6 and PC5 are -CE, -WE and -OE on the EEPROM, right?

I don't think you need a separate bus for the inputs to the 8-bit comparator - you can drive it from PA7~0.

I don't think you need the "8-bit switch" either - you can just disable the outputs on the 373 that drives the data bus when you want to read the data back from the EEPROM. You'll need a control signal for this; you could ditch port C and put all your control signals on port B. Then you're only working with two ports.

What's the part number for the EEPROM?

Is it 256x8? Or do you only need to access the bottom 256 locations?

Does it need any special voltages for programming?

The latches you're using are 373s, right? These are transparent latches which means you need to present the data, then drop the Latch Enable signal (pin 11) low to latch the data. So the basic process for programming a byte into the EEPROM would be:

  1. Set EEPROM -WE, -OE and -CE all high before you start.
  2. Set PA to the address to be programmed; set PC4 high
  3. Wait ~1 µs
  4. Set PC4 low (this latches the address into the address latch)
  5. Wait <1 µs
  6. Set PA to the data to be programmed
  7. Wait <1 µs
  8. Bring EEPROM -WE low; bring EEPROM -CE low
  9. Wait for the required amount of time for the byte to program
  10. Bring EEPROM -CE and -WE both high
  11. Loop to step 2.

The process might be different from this, depending on the type of EEPROM. Also, I've never used parallel EEPROMs so I might have got something completely messed up!

You don't need the inverter, and you don't need a latch for the data - just a tri-stateable buffer such as a 244. That's because you can leave the data on port A during the programming operation. You only need to be able to disable the drivers that feed port A to the EEPROM's data bus when you're verifying the data back.
 
Last edited:
The three signals on PC7, PC6 and PC5 are -CE, -WE and -OE on the EEPROM, right?

I don't think you need a separate bus for the inputs to the 8-bit comparator - you can drive it from PA7~0.

I don't think you need the "8-bit switch" either - you can just disable the outputs on the 373 that drives the data bus when you want to read the data back from the EEPROM. You'll need a control signal for this; you could ditch port C and put all your control signals on port B. Then you're only working with two ports.

What's the part number for the EEPROM?

Is it 256x8? Or do you only need to access the bottom 256 locations?

Does it need any special voltages for programming?

The latches you're using are 373s, right? These are transparent latches which means you need to present the data, then drop the Latch Enable signal (pin 11) low to latch the data. So the basic process for programming a byte into the EEPROM would be:

  1. Set EEPROM -WE, -OE and -CE all high before you start.
  2. Set PA to the address to be programmed
  3. Set PC4 high
  4. Wait ~1 µs
  5. Set PC4 low (this latches the address into the address latch)
  6. Set PA to the data to be programmed
  7. Bring EEPROM -WE low
  8. Bring EEPROM -CE low
  9. Wait for the required amount of time for the byte to program
  10. Bring EEPROM -CE and -WE both high

The process might be different from this, depending on the type of EEPROM. Also, I've never used parallel EEPROMs so I might have got something completely messed up!

You don't need the inverter, and you don't need a latch for the data - just a tri-stateable buffer such as a 244. That's because you can leave the data on port A during the programming operation. You only need to be able to disable the drivers that feed port A to the EEPROM's data bus when you're verifying the data back.

Kris, you are amazing :)

First off you are correct in assuming PC5-PC7 are OE WE and CE.

I agree the 8bit switch is pointless, my only guess is that it will keep someone from cheating (through the c++ code maybe) when it comes to testing if the EEPROM was indeed programmed correctly?

The data sheet says 256k(32kX8)? But I am only programming 256 pairs of address/data bytes.

Q1
-I did notice when I invert PC4 to enable the data latch (thus latching the address latch right?), the LEDS change to the data values. This means my addresses are not latching right?

Now for the numbered steps you provided:

Q2
-can steps 1-3 be set all at once, or should I send values CE WE OE, then send addresses, then send PC4?

Q3

Same question for steps 5-8. Set all the values at once or one at a time?


Yes I see what your saying, some of the components are unnecessary, but they make us build it their way :(

Thanks again!
You are awesome!
 

KrisBlueNZ

Sadly passed away in 2015
Kris, you are amazing :)
LOL Thanks :) There are several other people here who would have given a similar reply; I just got in first!
I agree the 8bit switch is pointless, my only guess is that it will keep someone from cheating (through the c++ code maybe) when it comes to testing if the EEPROM was indeed programmed correctly
Seems a bit silly to me.
Q1
I did notice when I invert PC4 to enable the data latch (thus latching the address latch right?), the LEDS change to the data values. This means my addresses are not latching right?
I think so. So you drive PC4 low, then assert the data on port A, and the LEDs change? There's a problem somewhere. As you said, when PC4 is low, the address latch should be remembering the latched input states. Its outputs shouldn't change when port A changes.
Q2
can steps 1-3 be set all at once, or should I send values CE WE OE, then send addresses, then send PC4?
I've clarified the list of steps and included explicit delays. Things that are listed in the same step can be done at the same time or in any order.
Yes I see what your saying, some of the components are unnecessary, but they make us build it their way :(
Bummer!

BTW what is the part number and manufacturer of the Flash EEPROM?
 
LOL Thanks :) There are several other people here who would have given a similar reply; I just got in first!

Seems a bit silly to me.

I think so. So you drive PC4 low, then assert the data on port A, and the LEDs change? There's a problem somewhere. As you said, when PC4 is low, the address latch should be remembering the latched input states. Its outputs shouldn't change when port A changes.

I've clarified the list of steps and included explicit delays. Things that are listed in the same step can be done at the same time or in any order.

Bummer!

BTW what is the part number and manufacturer of the Flash EEPROM?

Awesome, thanks for that clarification!

Yes, they do some sill things at my school LOL

I will have to do some debugging as to why my addresses aren't latching when I drive PC4 LOW. Just to make sure, OC gets grounded right? I believe you already cleared that up for me a few days ago, and it seems as though that is correct according to the datasheet.

I left my circuit in lab so I do not have the exact Part Number. :( I can update that later. Tomorrow I plan to fix the latch problem and give your great instructions a go! Hopefully I can get this thing functioning by the end of the day tomorrow!



I will probably be back for more help then :)
Much appreciated !!!
 

KrisBlueNZ

Sadly passed away in 2015
Just to make sure, OC gets grounded right? I believe you already cleared that up for me a few days ago, and it seems as though that is correct according to the datasheet.
Right. -OC on the address latch can stay permanently grounded to keep the outputs enabled.
 
LOL Thanks :) There are several other people here who would have given a similar reply; I just got in first!

Seems a bit silly to me.

I think so. So you drive PC4 low, then assert the data on port A, and the LEDs change? There's a problem somewhere. As you said, when PC4 is low, the address latch should be remembering the latched input states. Its outputs shouldn't change when port A changes.

I've clarified the list of steps and included explicit delays. Things that are listed in the same step can be done at the same time or in any order.

Bummer!

BTW what is the part number and manufacturer of the Flash EEPROM?

Awesome, thanks for that clarification!

Yes, they do some sill things at my school LOL

I will have to do some debugging as to why my addresses aren't latching when I drive PC4 LOW. Just to make sure, OC gets grounded right? I believe you already cleared that up for me a few days ago, and it see

I left my circuit in lab so I do not have the exact Part Number :( But tomorrow I plan to fix the latch problem and give your great instructions a go! Hopefully I can get this thing functioning by the end of the day tomorrow!



I will probably be back for more help then :)
Much appreciated !!!
Right. -OC on the address latch can stay permanently grounded to keep the outputs enabled.


I changed my code and it seems as though it is now working correctly. Using the numbered instructions above alleviated my latch problem, as I was switching PC$ LOW and changing the A bus from Address to Data at the same time, not allowing for a pause in just changing PC4 LOW 1st so that it has a chance to actually latch.

Unfortunately I don't think I am reading the EEPROM correctly. I have PC4-PC7 all HIGH initially to send the address value to the EEPROM for reading. Then I set OE and CE LOW to initiate a read. Now Data I/O pins should send corresponding data byte right? Then repeat with a new address value to read the next data byte.

Does this seem correct?

The EEPROm is a Atmel AT28c256
 

KrisBlueNZ

Sadly passed away in 2015
Unfortunately I don't think I am reading the EEPROM correctly. I have PC4-PC7 all HIGH initially to send the address value to the EEPROM for reading. Then I set OE and CE LOW to initiate a read. Now Data I/O pins should send corresponding data byte right? Then repeat with a new address value to read the next data byte. Does this seem correct?
Yes, but you can't read the data back with that hardware. All you can do is verify it against the expected value, using the "8-bit comparator". You need to load the address into the address latch and drive -OE and -CE low, like you said, and assert the expected data value on port B. The LED will indicate whether the data matches or not.

This comparator and LED is a bad idea, because the LED will flicker during programming, and even during verification because the Flash ROM's data pins will be undefined while -OE or -CE are high; even if you left them low during the whole verification pass, the read data from the Flash ROM would not change at the exact instant that the port B data changes.

So if you want a meaningful indication on the LED during the verify pass, you should leave -OE and -CE both low, and for each location you verify, you need to update the address and the comparison data as quickly as possible, then wait for a reasonable length of time, so the LED spends most of its time indicating the result of a valid comparison.

It would be a lot better to read the data back through a data port. In fact a sensible hardware design, given that you have two 8-bit ports and a 4-bit port, would use one 8-bit port for address, another 8-bit port for data, and the 4-bit port for control signals - no latches required. But I guess they want to teach you how to use latches, right?
 
Yes, but you can't read the data back with that hardware. All you can do is verify it against the expected value, using the "8-bit comparator". You need to load the address into the address latch and drive -OE and -CE low, like you said, and assert the expected data value on port B. The LED will indicate whether the data matches or not.

This comparator and LED is a bad idea, because the LED will flicker during programming, and even during verification because the Flash ROM's data pins will be undefined while -OE or -CE are high; even if you left them low during the whole verification pass, the read data from the Flash ROM would not change at the exact instant that the port B data changes.

So if you want a meaningful indication on the LED during the verify pass, you should leave -OE and -CE both low, and for each location you verify, you need to update the address and the comparison data as quickly as possible, then wait for a reasonable length of time, so the LED spends most of its time indicating the result of a valid comparison.

It would be a lot better to read the data back through a data port. In fact a sensible hardware design, given that you have two 8-bit ports and a 4-bit port, would use one 8-bit port for address, another 8-bit port for data, and the 4-bit port for control signals - no latches required. But I guess they want to teach you how to use latches, right?

I see what you are saying about the LED on the comparator, it would make sense to put a delay in order to easily check correct output like you mentioned.
And yes I think it would be much easier sending Data on the other 8bit port that is unused during the write.

So I have been trying to program this EEPROM all day but with no luck. Let me see if I have this correct:

I went through all of the steps you provided. Now as far as the 1us pauses, can they be longer, or will it interfere with the write? It is unclear to me in the data sheet.
Also, if it has to be on the microsecond level, how would you program that in c++. I know the Sleep() function but that is in milliseconds no?

Just to clarify, Step 10 "Bring EEPROM -CE and -WE both high" That is still with PC4 = LOW and the 8bit port = to the DATA? Then repeat setting OE WE and CE to HIGH and load the port with the next address etc?


Now to attempt to read the data back this is what I understand:

OE WE and CE are set to high. Set PC4 High and load address.Then set PC4 to LOW to latch data. (8bit switch is open for this part) Now Set OE and CE LOW. Now the EEPROM should load the data corresponding to the address latched?

I'm guessing set OE CE back High. Load the next adress and toggle PC4 for the next latch and repeat?


Sorry for all the questions, I have been here 7 hours straight trying to get this to work today. I feel like I am so close.


BTW I have LEDS displaying the DATA IO ports on the EEPROM. That way when I try to read back I can verify the data without the comparator. But so far nothing lights up when I try to read. So I am either programming it wrong or reading it wrong...
 
OK, to be more specific, Here is exactly what I am writing to my ports:
XX=Dddress
YY=Data


Here is my approach to programming the EEPROM

DAPI_WriteIoPorts(hDevInstance, 0x000F00XX, 0xFFFFFFFF); //PC4 and OE WE CE all HIGH
DAPI_WriteIoPorts(hDevInstance, 0xE00XX, 0xFFFFFFFF); //PC$ goes LOW-address latched
DAPI_WriteIoPorts(hDevInstance, 0x000600YY, 0xFFFFFFFF); //CE goes low, data is loaded
Sleep(100);
DAPI_WriteIoPorts(hDevInstance, 0x000200YY, 0xFFFFFFFF); //WE goes low
Sleep(100);
DAPI_WriteIoPorts(hDevInstance, 0x000600YY, 0xFFFFFFFF); //WE back high
DAPI_WriteIoPorts(hDevInstance, 0x000E0000, 0xFFFFFFFF); // back to top



Now to read from the EEprom I have

DAPI_WriteIoPorts(hDevInstance, 0x300XX, 0xFFFFFFFF); //sends address to be read by eeprom
DAPI_WriteIoPorts(hDevInstance, 0x3YYXX, 0xFFFFFFFF); //data sent on separate bus to verify




Right now this configuration does not work. Any help would be much appreciated.
 
I finally have this working!!!!

THANKS to all, especially Kris Blue ;)

Very encouraging to know there are extremely smart people here willing to help.

Mhanks again

Marc
 
Top