• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 81 subscribers
  • Views 2338 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

FRAM interfaced with MSP430 shows all memory bytes as garbage (0x32)

kunal bagewadi
Prodigy 120 points
Other Parts Discussed in Thread: MSP430F67791


I have Cypress FRAM FM24W256 connected to MSP430f67791 via I2C. My code has five 32-bit integers and accumulates a different count in each of them.
I have brown-out detection code which saves these 5 numbers to FRAM when voltage falls below 3V.
On reset, I read the numbers back from FRAM and continue to accumulate data into them and send these numbers out via Xbee on a UART port. This code and logic works fine and I keep the controller running 24x7 for few weeks. I reset the controller multiple times during the day.
But sometimes (say, once in 2 weeks), when I reset the controller, it reads a garbage looking value of 0x32323232 (842,150,400 decimal).
When few other controllers failed, I noticed that they too show this garbage looking value of 0x32323232.
I then read the entire 32K FRAM memory space and found that all bytes are 0x32.
The FRAM memory space is all zeros on another FRAM which did not show this problem yet.
Can anyone suggest why I see this same number in failing case ?

Configuration-
FRAM's WP,A0,A1,A2 pins connected to Gnd
MSP430f67791

IAR 6.10.1 for development

  • 0
    Mastermind 9125 points

    The working voltage of FM24W256 is from 2.7V to 5.5V. Five numbers are saved to FRAM when voltage < 3V. From the time "<3V" is detected to the time data is saved in FRAM, the voltage is varying since I2C module also needs a little time to transfer data. I guess FM24W256 may fail to work since the voltage might below 2.7V.

    How about using MSP430FRxxxx to replace MSP430F67791+FRAM?

  • 0 in reply to Robert Chen
    Prodigy 120 points

    Thanks for replying Robert.

    If the FRAM does not get enough time to save 5 numbers, then it would not save the numbers and I should have been able to retrieve last truly saved numbers.

    My confusion is why all 32K memory locations read back as 0x32. Please note that 0x32 is read only when the problem occurs, and then the MSP430 controller reads all five saved numbers as 0x32323232 and starts accumulating from this number. So the saved numbers look like this-

    day 1= 10, day 2= 500, day 3= 3400..... day 10= 20,000, day 11= 842,150,450 (which is 0x32323232). At this point if i read entire FRAM, it reads all locations as 0x32.

    In my code, I am touching only 20 bytes of FRAM for five 32-bit numbers.

    In my project, I am at a stage were I cannot change the MSP controller or FRAM chip.

  • 0 in reply to kunal bagewadi
    Mastermind 9125 points
    I don't know the internal implementation of this FRAM. But if the power is failed while it is programming data then what will happen? Take NAND flash memory as example, a block of memory will be erased as 0xFF before data is written. So, we probably get 0xFF if power is failed before the data is actually programmed.

    Cypress FRAM might have some "power cycling" issues. So, you probably have to ensure the power is stable when writing data to FRAM. Otherwise, unexpected will happen as what you have encountered.
  • 0
    Guru 100785 points

    No, I haven't seen this exact symptom with FRAM.


    That said, I always protect myself by (1) including a CRC (or, if I'm feeling cheapskate, a checksum) (2) writing to two different FRAM areas -- either duplicate copies or ping-ponging for consecutive snapshots.

    FRAM is quite fast and low power. You have (32K-20) bytes and "infinite" write endurance to work with. Have you considered writing snapshots periodically, rather than only in an emergency?

    As a diagnostic, consider the possibility that you're not seeing 0x32 from every location, but rather the same 0x32 over and over again -- i.e., a bus or firmware thing rather than a memory thing. A scope on SDA/SCL might (or might not) be enlightening.

    Is this condition permanent? If you reset your counters back to 0 and run for a while, do you still get 0x32s back?

  • 0 in reply to kunal bagewadi
    Guru 100785 points
    > If the FRAM does not get enough time to save 5 numbers, then it would not save the numbers and I should have been able to retrieve last truly saved numbers.

    This is incorrect. The data is written by the FRAM chip as it is received. There is a very real possibility that the power will go out in mid-transaction, so only part of the data gets written. This is where CRC+duplication comes in.
  • 0 in reply to Bruce McKenney
    Guru 11940 points

    Have you considered writing snapshots periodically, rather than only in an emergency?

    I suspect this might be the key. Using similar FRAMs in commercial projects, I never experienced such a problem. But I remember former projects, where (Flash/EEPROM-based) emergency write procedures caused much the same trouble. I would bet on a software issue (an application bug), rather than a hardware related one.

    That said, I always protect myself by (1) including a CRC (or, if I'm feeling cheapskate, a checksum) (2) writing to two different FRAM areas -- either duplicate copies or ping-ponging for consecutive snapshots.

    Such kind of checksum-protected entries are highly advised. That includes backlogs of former entries as fallback, especially for that case.

  • 0 in reply to Bruce McKenney
    Prodigy 120 points
    Thanks for responding.

    >>> Have you considered writing snapshots periodically, rather than only in an emergency?
    Yes, I already have that logic to save to FRAM every 30 mins, in addition to saving on brown-out condition.

    >>> Is this condition permanent? If you reset your counters back to 0 and run for a while, do you still get 0x32s back?
    No, if i reset the counters then it reads back as 0 after reset. The other FRAM locations still show 0x32 unless i overwrite there. So the problem occurs just once a while and then the controller begins accumulating these counters from 0x32323232 and save correctly, only that now the saved number is garbage-looking.

    >>> consider the possibility that you're not seeing 0x32 from every location, but rather the same 0x32 over and over again
    I dont think so because when i see the problem after a reset i read my counter value as 0x32323232 and it begins accumulating further. Then if i reset again i read correct value which is just over 0x32323232 because it accumulated in the time between resets. At this time, all other FRAM locations still read 0x32. I also had a test code written just to read entire FRAM and tested it with known FRAM contents and i could read correctly. I used the same test code to read failed case system and it showed all locations as 0x32.
  • 0 in reply to f. m.
    Prodigy 120 points
    Thanks for replying.

    I understood the importance of CRC.
    Even if i include a CRC, i will only know that the data is corrupted but i cannot have a corrective action because the count is lost permanently and my application is then useless.
    The duplicate copy would come in handy if only those 20 bytes of data were corrupted. In this issue, the entire FRAM gets corrupted. So even if i had a backup copy in FRAM that would turn to 0x32 as well. With my test code to read entire FRAM, i can confirm that entire FRAM reads as 0x32 when the problem occurs. So the counters start incrementing from 0x32323232 and overwrite the wrong-looking value correctly going forward.
  • 0 in reply to kunal bagewadi
    Guru 100785 points
    Another thought (heading back into Robert Chen's territory): Is your SVS set appropriately for your MCU's clock speed?
    My experience with running the CPU faster than Vcc permits (oops) is that it doesn't just freeze or reset, rather it acts 'goofy' -- random branches, unexpected register contents -- and unpredictably. The main goal of the SVS of course is to prevent stuttery behavior in the boundaries of the MCU's voltage range, and with that XBee there it's probably drooping pretty fast.
  • 0 in reply to kunal bagewadi
    Guru 11940 points

    Even if i include a CRC, i will only know that the data is corrupted but i cannot have a corrective action because the count is lost permanently and my application is then useless.

    That depends on your application, and the use case you have in mind.

    Mine is storing application settings 'across' power-down/power-ups. If the dataset is corrupted, you can detect it, won't restore incorrect parameter. You can use a Flash-based default set, or an even older data set, instead.

    The duplicate copy would come in handy if only those 20 bytes of data were corrupted. In this issue, the entire FRAM gets corrupted

    I'm aware of that. And still I think the cause is a software bug. If the corresponding routine is only called in "emergencies" (power loss), it might admittedly be difficult to reproduce and catch.

    My cited example was referring to a Flash/EEPROM based application (on a totally different MCU). The slow, cumbersome and energy-hungry Flash write turns out as advantage in this case - only one dataset got corrupted ...

  • 0 in reply to f. m.
    Prodigy 120 points
    Everyone,
    I found that a pointer bug was writing 0x32 to all locations of FRAM. Thank you everyone for responding and thinking about the issue.
  • 0 in reply to kunal bagewadi
    Mastermind 9125 points

    No problem. It's great that you find the bug.

**Attention** This is a public forum