EEPROM will always read, but not always write.

[Nick]

I'm having a wierd problem. I can always read the EEPROM but not always write it. I'm positive that the ext_eeprom_write functions are being called. Anyone have any ideas? I can post code if it will help. I'm compiling on 3.091

Nick

[SherpaDoug]

Writing takes time. Are you sure you are waiting long enough?
_________________
The search for better is endless. Instead simply find very good and get the job done.

[Neutone]

When attempting consecutive writes the prior burn may be incomplete and cause the following write to be rejected. check the busy flag to be sure.

[Nick]

thank you, that sounds like the problem.. consecutive writes.

Nick

[Nick]

I did a help file search for busy flag and didnt pull up anything. I did that on the new version and the old one. Where can I find information about the busy flag?

Nick

[Neutone]

Do a search of the data sheet for the EEPROM you are using. You have to read it by I2C if I remember correctly.

[PCM programmer]

[Nick]

after some more testing it looks like the problem is that the data is wrapping.

for example

sending
10000000000121 is fine but


1000000000012131 ends up like this
13100000000121


the data wraps to the fron, but the eeprom is not even close to being filled.

Nick

[Nick]

FF is Last address on the EEPROM before it starts the wrap... btw there is alot of space left on the eeprom.

Nick

[PCM programmer]

Some questions:

1. What is the part number of the EEPROM that you're using ?
(ie., 24LC256, 24C64, etc.)

2. What driver are you using ?
(ie., 24256.C from CCS, etc.)


Comments:
Notice in the function declaration of the routine that I just posted,
that the address is a 16-bit value. (In CCS, a long int is 16-bits).
void write_ext_eeprom(long int address, BYTE data)
The symptoms that you describe could occur if you passed only
an 8-bit variable to that function for the address.

Another possibility is that you could be using the EEPROM in Page Mode,
and if the page size was 256 bytes, then it would certainly wrap if you
sent more than that at one time.

To help you any further, we need to know what EEPROM you're using
and what driver you're using.

[Nick]

I should kick myself in the butt for not giving that information in the previous post.


the eeprom is a 24LC32A, and the drive is one you posted awhile back. I found it using the search engine. I believe its for a 24C256. The reason I was using it was because the demo didnt have one, but now I have an 3.091 full version.

Thank you again for your help.

Nick

[PCM programmer]

Vs. 3.091 comes with a 2432.c driver file. It's in this folder:
c:\Program Files\Picc\Drivers
That version of 2432.c has an 11 ms delay at the end of its
write routine. The 24LC32A is spec'ed at 5 ms max write time,
so you could edit the driver and reduce the delay to say, 6 ms.
After you get it working, you could add ack polling.

---

So, are you using that driver, or are you still using one that
you found on the net ? If you're using the 2432.c driver,
and you still have problems, then please post a short demo
program that calls the driver functions, and demonstrates
the problem.

[Charlie U]

You mentioned that FF is the last address where it starts to wrap. This may be obvious, but are you aware that each consecutive write or page write to the 24LC32, is limited to 32 bytes, and can not cross a multiple of 32 boundary? You can start a consecutive write, where multiple bytes are transmitted in a single command, at any address, but the last byte can not go beyond the 32 byte boundary. As I recall, it will wrap to the beginning of the page and overwrite other data. Take a look and see if this is what you are experiencing.

[Nick]

yup,that was the problem


I was using a INT in one part, swapped it out to a LONG INT and it runs!

Thanks!

Nick