Shop OBEX P1 Docs P2 Docs Learn Events
24LC32A EEPROM Issue — Parallax Forums

24LC32A EEPROM Issue

Earl FosterEarl Foster Posts: 185
edited 2008-01-03 01:47 in BASIC Stamp
Hi all,
I have come across an anomaly that I can not pin down.· It seems that when I am writing to the 24LC32A chip using "P" or "PX" stamps everything·seems to be·recording fine for a while then I get a hiccup, records fine again for a while, then another, and so on.· Meanwhile, on my terminal screen every looks fine throughout the entire recording process.· I have changed out 24LC32A's and the same thing occurs at the same location (See·data dump·below).· I have also tried to look at bit and byte positions for a pattern but I have not been able to find one.

My questions:
Are there any known bugs with this chip? (Probably not, but gotta ask)
Are there any locations in the chip that have special meaning that I should not be writing too?
And, most likely, could it be the way I am writing to memory?

Any help·would be appreciated.· Anomalies are the hardest issues to troubleshoot.· But it is a consistent anomaly at least.

...code sniplet
' This procedure is used for WORD size variables
' wrdAddr and x are passed to subroutine
' wrdAddr is passed back to main procedure with new starting value
Write_Word_Data:
·· I2COUT SDA, $A0, wrdAddr.BYTE1\wrdAddr.BYTE0, [noparse][[/noparse]x.BYTE0, x.BYTE1]
·· wrdAddr = wrdAddr + 2
RETURN

' This procedure is used for BTYE size variables
' wrdAddr and x are passed to subroutine
' wrdAddr is passed back to main procedure with new starting value
Write_Byte_Data:
·· I2COUT SDA, $A0, wrdAddr.BYTE1\wrdAddr.BYTE0, [noparse][[/noparse]x]
·· wrdAddr = wrdAddr + 1
RETURN
...end code sniplet


Partial data dump from the chip.· Red line is the anomaly that occurs at 7 locations.·
attachment.php?attachmentid=73709
Full code is attached just in case someone wants to look through it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HABP.NET

"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman
494 x 280 - 10K

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2008-01-02 23:22
    The pattern of locations are odd. It may have more to do with what else you're doing. All EEPROMs require extra time to write the data to the EEPROM array. Typically you allow at least 5ms for each write (and I don't see a delay in your write routine). If you can transfer more than one byte per write operation, that can save a little on time. The multiple bytes have to all fit on one page whose size is defined by the device. For the 24LC32A, I think that's 32 bytes.
  • Earl FosterEarl Foster Posts: 185
    edited 2008-01-02 23:52
    I placed a 5 ms pause statement right after the IC2OUT statement in both procedures as you suggested and reset memory but the anomaly still exists.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    WWW.HABP.NET

    "Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman
  • Mike GreenMike Green Posts: 23,101
    edited 2008-01-03 00:12
    Again, the paged write stuff may be related. I can't tell from what you've posted, but the situation is as follows:
    Some sequence of writes puts the first byte of a word to be written at the end of a block of 32 addresses and
    your program attempts to write two bytes. Because both bytes are in one I2COUT, the first byte will go in the
    expected location. The second byte will be written at the beginning of the 32 byte "page" rather than the location
    following the first byte. In the first case at 255, the LSB will be at 255 and the MSB will be written to 224 rather
    than at 256. It may be that the pattern of single and double byte writes just crosses a 32 byte boundary in the
    middle of a word at those locations.

    Solution is either to always write a word starting at an even address or split a word write into two separate
    byte writes (and their 5ms pauses).
  • Earl FosterEarl Foster Posts: 185
    edited 2008-01-03 01:47
    I understand what you are saying now with respect to the 32 byte page. I went back and reviewed the page write operations and if the master should transmit more then 32 bytes prior to generating the stop condition, the address counter will roll over and the previously received data will be overwritten which would explain why I was getting garbage once in a while.

    I made the write word statement into 2 seperate statements per you suggestion and it fixed the problem.

    I really appreciate your help with this one.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    WWW.HABP.NET

    "Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman
Sign In or Register to comment.