• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 603 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.

CC2652R: Corrupted on-chip flash

Grant China
Prodigy 110 points
Part Number: CC2652R
Other Parts Discussed in Thread: SIMPLELINK-CC13XX-CC26XX-SDK

Hi, I've got an application running on a CC2652R and somehow the on-board flash is very intermittently getting corrupted. Out of a sample size of around 50 prototype units running 24/7 for several months, we've seen the flash getting corrupted 3 times on different units. In our application, this corruption is essentially bricking our device.

Our application is directly calling the NV functions in the ZCL porting layer and its function pointers are set to use the NVOCMP driver functions in nvocmp.c. The call in my code that is failing is zclport_initializeNVItem(). I've traced down into this call in the debugger and it's failing at NVOCMP_findItem(), which is returning a value of NVINTF_CORRUPT.

Our application is currently using a total of 16 different NV items. When this corruption occurs, all of our items are reporting NVINTF_CORRUPT. The application basically writes to most of the NV items once at initialization and after that only reads those items at boot time. There is one NV item that is written to relatively frequently.

Two units ended up corrupted after writing their initialization values and came up bricked on the next boot. The other unit that ended up corrupted had been running a test that wrote to one specific item once every 15 minutes. In an attempt to reproduce the flash corruption, I set up another test unit to write to the same specific NV item continuously and it wrote thousands of times. So far, I have not been able to reproduce the problem.

To be clear, I'm only assuming that the most likely time that flash memory would get corrupted is during a write operation. I don't have any direct evidence that the corruption is occurring on a write operation.

Anyway, I'm trying to understand what could lead to this kind of corruption. What could lead to the NVOCMP functions returning NVINTF_CORRUPT?

While I wouldn't normally suspect a hardware component to this issue, it's interesting to note that we have another CC2652R based design that we have been testing for a considerably longer time and I have never seen the corruption on the other design. I haven't got enough of units to be statistically significant though.

Thanks,
Grant

  • 0
    TI__Guru**** 219997 points

    Hi Grant,

    The most common reason for NVINTF_CORRUPT is when there is not enough power to safely write to flash memory.  What is the supply voltage for the device, have you monitored the power supply to ensure that it is steady/sufficient, are the devices subjected to unexpected power shutdowns/resets or ESD, and have you implemented Non-Volatile Memory Low Voltage Detection?

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 110 points

    Thanks, Ryan, you've certainly given us something to chew on.  Our product is not battery powered but we'll take a look at the stability of our power supply.  Given that we're not battery powered, I haven't looked at the NV Memory Low Voltage Detection but I'll take a look at it.

    None of the devices that have corrupted their flash so far have been subjected to any ESD.  It's possible that they may have been subjected to power shutdowns/resets at inopportune moments.  In general, they almost never write to NV memory so it's unlikely that power went out in the middle of a write.  Of course, "almost never" is not quite never.

    Regards,

    Grant

  • 0 in reply to Grant China
    TI__Guru**** 219997 points

    The difficult part about debugging such an NV issue is that it does not appear to be easily reproducible.  It does not appear that the maximum flash write cycle limit is being exceeded for the device.  If you re-program the faulty boards and the NV becomes corrupted again, whereas other boards continue to run as expected, then this could indicate a hardware problem.  Which SIMPLELINK-CC13XX-CC26XX-SDK version are you using and how do you initialize and read/write the custom NV items?

    Regards,
    Ryan