• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 52 subscribers
  • Views 369 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.

CC2642R: Flash Writes to Cannot Overwrite Already Written Values

TylerWitt
Intellectual 810 points
Part Number: CC2642R

Hello,

I think I found out a "feature" of the flash that I need to design for, but I want to get confirmation on it prior to actually implementing this to make sure I'm correct about it.

For our application, we have segmented one 8kB block out as "GP Flash" where we can write our firmware version, keep track of device specific information, and backup our RTC value (among other things). Well, in attempting to do the last of those operations and save the RTC value on demand, overwriting a Flash location with the updated RTC seconds value, I noticed that the operation continually fails, but only if I do not erase the block first. Meanwhile, in our flash initialization routine, we are easily able to read/erase/write the same flash location.

More technical detail, when I attempt to backup and overwrite the value, it returns from the flash write with FAPI_STATUS_FSM_ERROR. Digging into this further, I found that the FMSTAT register held a value of 0x00000030 (INVDAT | CSTAT). On other posts across the forum, these values have meant that the "data needs to be erased before reprogrammed."

Is this also the case for the CC2642R? Do I need to read/erase/write every single time I want to update a value in the block I have segmented for general purposes?

The only notation I see in the reference manual is about "a maximum of 83 write operations within a row between erases."

Is this assuming that each write is done on already erased flash?

Another thing from the data sheet: "Supported flash erase cycles before failure, single sector = 60k." So if we are trying to backup the RTC once an hour, we will have erased 60k times in less than 7 years, not counting any other erasure causes on that entire block.

Does this make sense? Do I also need to write a wear-leveling algorithm so we don't kill the flash with erase cycles?

Regards,
Tyler Witt

  • 0
    TI__Intellectual 1975 points

    Hello Tyler,

    TylerWitt said:
    Is this also the case for the CC2642R? Do I need to read/erase/write every single time I want to update a value in the block I have segmented for general purposes?

    In general, flash is erased by charging up an entire sector (8kB in this case) to have a digital true value. "Writes" are then individual bits being pulled to ground. So to go from 0 to 1, the entire sector must be erased. So to answer your question directly, you are correct. a read/erase/write is necessary. I recognize the sparse documentation on this. Please visit the TRM section 8.5 for the relevant documentation.  It seems you've already seen this either way.

    If you have the available space for 16kB, I would actually suggest you make use of the NVOCTP (NV on-chip two page) module. Check out the link to learn the basics of the module. The disadvantage here is it requires 2 pages. The advantage is that it does item management so the erases are hidden from the you the user. I have found the module to be reliable and easilly simplify nv data storage.

    TylerWitt said:
    Is this assuming that each write is done on already erased flash?

    Actually no. This is assuming write operations to different bits in the the row.

    Another advantage to NVOCTP is that it takes the write limits into account. The driver minimizes write operations for small items. Each item has a header and therefor a min size so it is impossible to fit enough items in one row to get to 83 writes.

    TylerWitt said:
    Does this make sense? Do I also need to write a wear-leveling algorithm so we don't kill the flash with erase cycles?

    This is something that is not solved directly from NVOCTP and would have to be accounted for in some way by you.

    One option, and this is something that has not been attempted to my knowledge is the following. 

    Assuming you are not space constrained, you could allocate several 2 sector regions in the board file. Then periodically close the NVOCTP, copy the region over to the next 2 sector region and reopen NVOCTP against the new region. This would allow a quite rudimentary kind of wear leveling but would also take some doing on your part.

    I hope this answers your questions!

    Best,

    Kris