Need some assistance with 28C64B EEPROM project.

[Photometric Guy]

Hello people,
I’m currently working on a glcd project that has me pulling my hair out for two weeks now. This is what I have going on: I’m building a graphical lcd project that pulls bitmap data from a Atmel 28C64B-15PU eeprom and displays it on the glcd. The project uses a VB6 application I built to upload bitmap data to a PIC16F871 that then writes the data to the eeprom. After the upload the PIC then has the option to pull data and display it on the glcd. I’ve slowly been dismantling the project to find the bug but it’s an elusive one! I’m now to the point of trying to write directly to the eeprom through the PIC’s UART via HyperTerminal then try to read the contents back. All I get is garbage. I’ve played around with different timings and I can get back repeating characters for all address locations after I write to just one address. I can use the glcd in place of the eeprom (with some tweaking) and view the data as it’s downloaded but I just can’t seem to write to the eeprom. The 16F871 is capable of 200uS execution (more like 800uS bus with Picbasic) and the data sheets for the 28C64B spec 150nS as min. and nothing for Max. timing. I’ve tried using decoupling caps., shorten the wire on the breadboard and pulling all unused pins to G. I also tried increasing hold times to offset pin capacitance. I’m almost convinced that it’s a timing problem or a noise/bounce problem. The data sheets are minimal, simplistic, and unclear as to how the latch registers work among other things on the 28C64NB. I’ve googled it and can’t find any articles or ideas on interfacing a 8bit parallel eeprom to a pic. I could use serial memory but then the graphics update is too slow. Anyway I already bought some of these chips. Anyone have any ideas?

 

[Pommie]

When writing to the ROM the maximum time between successive bytes is 150uS. If this time is exceeded then an internal write starts and you have to pole the chip to see when it has finished. If, after each write, you read back the same location until it is the correct value, then it should work correctly. Have a read of the section titled "page write" for further explanation of the above.

You should be aware that writing one byte at a time will result in only 100 bytes per second being written. You will need to take this into account in the program sending the data.

Mike.

 

[Photometric Guy]

That’s good advice and I know that my MCU is too slow to execute a successive page write. I have been polling the I/O7 pin and checking I/O6 pin for toggling states before attempting to read or write again. I’ve studied the data sheet for weeks. I’ve even read competitor chip’s data sheets to help ‘fill in the gaps.’ Any more ideas?

 

[Pommie]

A few questions, if you read back the written location until it reads correct, how can it read different later? How long is it taking to write the whole 8K? - it should be around 80 seconds. How are you making the VB app wait so the UART doesn't overflow?

Just asking the questions as sometimes the right question is all it takes to fix the problem.

Mike.

 

[Photometric Guy]

OK, Let’s say I’m going to write ASCII “A” to address 01h then try to read address 00h to 40h and send the data back to my terminal. If I use the polling method I get the “A” at 01h back AND all the other addresses have corrupt garbage in them. If I then write “B” to 02h the garbage changes again, sometimes corrupting 01h too. If I don’t use polling and just wait a few seconds after each write to be absolutely positive the chip has enough write time, let’s say I write “A” to 01h, wait then write “B” to 02h, wait again then “C” to 03h then wait a few more seconds and read back 00h to 40h I’ll get “C” back or the last character written for 00h through 40h even though I didn’t write all of them. It’s almost like the chip does it own page write filling the eeprom with the last character without using WE. I then tried another chip with the same results. I wrote “A” to 01h on a fresh chip and it filled the eeprom with garbage.
As for the other part of your question I handshake by passing Ack. Back to the terminal when the PIC is done and the UART is ready for the next byte.

I noticed that the data sheet has a AC driving level diagram indicating Vhi as 3.0v. I’m driving them up to Vcc @ 5V but can’t imagine this would be a problem. I also can’t help but wonder when I see the phrase: ‘this parameter is characterized and is not 100% tested” throughout the data sheet.

By the way thanks for trying to help out Mike. I really appreciate it.
Dan

 

[Pommie]

It’s almost like the chip does it own page write filling the eeprom with the last character without using WE.

That's weird because the DS states "Only bytes which are specified for writing will be written; unnecessary cycling of other bytes within the page does not occur."

I noticed that the data sheet has a AC driving level diagram indicating Vhi as 3.0v. I’m driving them up to Vcc @ 5V but can’t imagine this would be a problem. I also can’t help but wonder when I see the phrase: ‘this parameter is characterized and is not 100% tested” throughout the data sheet.

The DS states "Single 5V supply".

By the way thanks for trying to help out Mike. I really appreciate it.
Dan

Doesn't look like I'm much help at the moment.

I did notice in the DS that there is the ability to multiplex the data and address lines due to the fact that the address is latched when /WE goes low and the data when /WE going high. I assume you set everything up and then just pulse /WE low. Could you post your write code in case there is something your missing. Have you tried writing actual values rather than toggling bits in case it's a RMW problem.

Added, Have you tried writing a whole page. 150uS is a long time even in basic. If you are running at 20MHz then 150uS is 750 instructions. I think you may have confused nano and micro above. The pic bus speed being 200nS.

Mike.

 

[Photometric Guy]

I double checked the PIC data sheet and I was confused with the speed, my bad, thanks. Your correct, I setup the address and data then just toggle the WE pin. I’ve also tried toggling the CE pin with WE low and toggling both. As for the toggling of bits I tried both toggling and writing direct. I haven’t tried to write a page as of yet. I should set up the project again. I never tried other ports on the MCU either. I could post my code if I clean it up a bit, I’ve no-frills hacked it to death, It’ll take awhile. I use Melabs Pic basic because it’s fast & easy. The drawback is that you can’t calc timing by counting instructions. I was hoping someone out there knew of a quirk with this prom. Have you used this prom before with good results?
Dan

 

[Photometric Guy]

Thanks for the help Mike. I've got it under control now.
FYI: I turned off the PIC’s UART port and simulated it in software. Everything works as expected now. I’m skeptical that the UART was the problem. The bug was probably right under my nose I just couldn’t see it, wouldn’t be the first time.