• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 54 subscribers
  • Views 1821 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.

CC2540 Flash Page Corruption

Mack Wilz54
Prodigy 250 points

Other Parts Discussed in Thread: CC2540

Over 3 different products that use the CC2540F256 we have witnessed a small percentage of devices getting flash pages set to 0xFF. This normally occurs, from what I can tell, when the device is power cycled. Is there any reason why entire flash pages of program memory would go missing (be reset to 0xFF)?

  • 0
    TI__Mastermind 20480 points
    Are you using the BLE SDK? If so, which version?
    With the BLE SDK, there are 2 flash pages used for the "Simple Non Volatile" SNV storage. Are you perhaps seeing erasing happening between these 2 pages?

    Tom
  • 0 in reply to Tom Kopriva
    Prodigy 250 points

    There are NV flash pages in our code, but those are not the pages that are being erased. The flash pages that are being erased are actual code pages based on the .map files created upon build. The Three products have all started from different TI sample baselines and then were customized to fit our needs. All baselines are using a version of the BLE 1.4.x Stack.

  • 0 in reply to Tom Kopriva
    Prodigy 250 points
    Tom,

    We are still trying to find some resolution on this? Would any information (hex file dumps, .map files, etc.) help you or anyone else with diagnosing this issue?

    Thanks,
    Mack
  • 0 in reply to Mack Wilz54
    TI__Guru** 105180 points
    Hello Mack,

    Can you provide more details on how you are able to know the issue occurs on a device reset?
    Have you performed ESD testing on your device? We have seen devices experiencing ESD outside of the data sheet specification in which flash erasing is a failure mode (i.e., due to errant PC jump to erase code). This has occurred when the device specifications are exceeded.

    One option would be to use the flash lock bits to prevent an erase. That may or may not be an option in your case, but something worth looking into.

    Best wishes
  • 0 in reply to JXS
    Prodigy 250 points
    I am not sure if it is due to reset or not. One of the products frequently power cycled the device and went from working when it was on to not working when it was on. The reason was flash pages erased. The other reason I may think this is the case is from this post in the forum:

    e2e.ti.com/.../208145

    At the bottom of page 1, TI employee Fredrik K is wondering about powering down time or time through a specific power range and instructs the OP to remove a capacitor to speed this up.

    I don't think it is ESD as the 2 of the 3 devices are intrinsically safe with the CC2540 being fully potted. Lock bits may work on some devices, but definitely would not work on others as some of them need to be field updated and are using TI's OAD project for this purpose. The device with this firmware had a corrupted Img B and Img A and the BIM was putting the device into PM3 until a HW watchdog was resetting the device. Then Loop through the CRC checks and back to deep sleep.

    Is there any other things that may occur that have been confirmed to erase flash pages?
  • 0 in reply to Mack Wilz54
    Intellectual 690 points

    Hi Mack,

    I just had a similar issue occur with one of my devices.  Did you ever figure out what was causing the flash to be erased?  In my case it appears that only one page was erased, which happened to be the first application page at address 0x1800 (the first 3 pages are the bootloader in my case).

    Thanks,

    John

  • 0 in reply to J.Sample
    Prodigy 40 points

    Did anyone ever find the cause for this?

    It seems we experience a similar issue here as well. All data up to 0x7F00 was erased (reset to 0xFF).

    /Peter

  • 0 in reply to Peter Olsson
    Prodigy 40 points
    I got the wrong addresses in my previous post. The sector that has been erased is 0x0000 -->> 0x07FF.

    We have nothing in the code that writes to flash, so there must be something else going on here...

    /Peter