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 memory corruption

Part Number: CC2540

CC2540 flash page corruption

 All data up to 0x7F00 was erased (reset to 0xFF).

The BLE has 1.4.x Stack.

This issue has been reported previously. https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/532630?CC2540-Flash-Page-Corruption

Was there any resolution to this found?

  • Hey Sanjay,

    I've assigned an expert to comment. Can you try to reproduce this on the 1.5.x version of the stack?

  • Thanks Ammar!

    I currently have issues reproducing it on 1.4.x however this has definitely happened on more than 5 customer returned devices. The device supports over the air updates but I haven't found any problem with that. Once I flash a new BLE image, the BLE module work as expected.

    I can try reproducing the issue on 1.5.x as well.

  • Sanjay,

    I'm sorry for the delay in my response.

    Thanks for the report. I know this is a tricky one, but do you know the circumstances surrounding the issue occurrence?

    For example,

    • did the problem occur while doing over-the-air update?
    • or during power cycle?
    • or simply just out-of-the-blue?
    • any information would be valuable

    The only relevant information I have is a note on the "Known Issues / Limitations" on the readme file for this release, related to NV memory. It states: "It is therefore recommended that the NV memory be used sparingly, or only when a connection is not active."

    Given that, could you tell...

    • ...if the application uses heavily the NV memory? or,
    • ...if it uses it when connections are active? 

    Since the issue could potentially be related to the NV wear-leveling algorithm, could you tell if these failed units have been in the field for a long time?

    In any case, I will be in contact with our dev team to investigate the issue. 

    I look forward to hearing from you.

    Thanks,

    Luis

  • Thanks Luis

    Adding more info; the code on the flash memory (256K) is erased. Mainly the BIM on the first page is completely erased (FF). The application code is only using 116 182 bytes of CODE memory (+ 10 794 range fill)

     I had to re-flash the whole image (BIM + Application) on each of the device using the CC debugger. I have tried different tests (as below) however couldn't reproduce the issue. The same flash corruption I have now noticed on a few more devices which were in the field from last 1 the year.

    - Tested the re-flashed devices at extreme temperature ( > 40DegC)

    - Used a variable power supply (3.6V) and then reduced it down to 1.5 V (test brown out ) and after some interval increased back to 3.6V

    - Repeatedly over the air updating the same Bluetooth image

    Yes the application uses the NV memory however the connections are not frequent.

  • Sanjay,

    Thanks for all the details. I will report this to our dev team to investigate the issue.

    I might come back to you with more questions.

    -Luis

  • Sanjay,

    After discussing with the team, I found that we have not observed this condition on TI reference hardware. We have in the past seen this issue on some customer boards. In these cases, the issue was traced to a variety of causes, such as improper layout (i.e. not following the TI reference design) especially around clock and ground paths, inadequate ESD protection, inadequate power supply, or errant SW, like an application C stack overflow. Given that you only see the issue on a few boards, I would suggest reviewing your HW layout and ESD testing results first. Additionally, TI can assist you in reviewing your hardware design. If you're interested, please submit a ticket in the following link. https://www.ti.com/tool/SIMPLELINK-2-4GHZ-DESIGN-REVIEWS

    Thanks,

    Luis