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

CC2541 flash memory corrupt

ikon
Genius 5355 points
Other Parts Discussed in Thread: CC2541

Hi Support,

We have a case of one unit that is returned from customer. The unit was functioning before.

I put the unit in the programming jig, I am able to retrieve the MAC address.

Then I proceed with re-programming the device, and the device revive.

 

Could you help to check if there is a case in CC2541 where to unit lost / corrupt its NV memory?

We are using it for tennis, so would it be possible if the shock corrupt the NV memory?

What is the maximum mechanical shock that TI CC2541 specs?

Is there a possibility that the strong mechanical shock corrupts the memory inside the MCU?

We don’t understand how the CMOS level works when expose to this environment.

Thanks.

  • 0
    TI__Guru** 105180 points

    Hello Shaun,

    It would be good to compare the image extracted from the returned unit with the default firmware image. You should only expect differences in SNV (if enabled) and 4 bytes within the Stack image for TX Calibration data. If you don't see any differences outside of these regions, then likely it's not corruption due to shock. Also, I would try to power up with the CC Debugger attached to see how far in the initialization you get before an error is presented. These should be good first order debug steps.

    Best wishes

  • 0 in reply to JXS
    Genius 5355 points

    Hi Support,

    I have several units that I have extracted the images and could be compared with the original firmware.

    But can you help to explain what is SNV? And how to get this 4 bytes within stack image?

     

    Also when I connect this "corrupted" unit with cc debugger. I can read the unit mac address and other thing such as read hex using cc flash programmer gui. What initialization that you mean?

     

    Can TI confirm there is a case where flash memory corrupted due to high shock (once reprogram then the MCU works normally again)?

    What is the G-shock limit that the chip level has been tested at?

     

    Thanks.


  • 0 in reply to ikon
    Genius 4470 points
    Hi Shaun,

    SNV is Non-Volatile Memory areas that can be used by developer to store some data that need to be persist after power reset of the device. It can be accessed using osal_snv_read/write function calls.

    Can you elaborate what is not working in the damaged device? Are you using these NV locations ?

    Thanks,
    Dhaval
  • 0 in reply to Dhaval V
    Genius 5355 points

    Hi Support,

    The memory areas that is corrupted, resides in Flash area which is the 256KB flash.

     

    I attached an analysis on one of the RMA unit from customer.

    This RMA units initially behaves correctly, but after several use, the unit is unable to broadcast the signal.

    The left "unit A" refers to the memory map of the golden unit, right "unit B" refers to the memory map of the RMA unit.

    As you can see, there are 3 lines of code that is different (the last one is different among the unit, so it is fine).

    These lines of code are corrupted, and we are questioning whether there is a possibility of corruption due to shock.

     

    Also help to respond: Can TI confirm there is a case where flash memory corrupted due to high shock (once reprogram then the MCU works normally again)?

    What is the G-shock limit that the chip level has been tested at?

     

    Thanks.

  • 0 in reply to ikon
    TI__Mastermind 18780 points
    Do you know what happens to the power during the shock?
  • 0 in reply to ikon
    TI__Guru** 105180 points
    Regarding "QLIPP RMA Unit 14.xlsx", what areas of the map file do the modified regions correspond to?

    Best wishes
  • 0 in reply to CHS
    Genius 5355 points

    Hi Charlotte,

    To your queries:

    1. We do not know what is happening on the power during the shock (i.e. voltage transient produced by capacitors, etc). Can you let me know your input on this matter?

     

    2. As refer from previous feedback:

    "If you don't see any differences outside of these regions, then likely it's not corruption due to shock."

     We would like to clarify whether it is possible to have corruption in this region due to shock.

     

    3. Also, does SNV region resides outside code flash memory?

     

    Thanks.

  • 0 in reply to ikon
    TI__Mastermind 18780 points

    I will let comment on the QLIPP RMA Unit 14.xlsx file you attached earlier.
    We have not tested for mechanical shock, this is something that the application must protect against. Normally flash issues are related to SW, but if you have fast dips in your power, you can get issues. That was why I asked about the power.

  • 0 in reply to CHS
    Intellectual 300 points

    Hi CHS,

    I am the customer, currently we have about 8 units have "memory corruption" issue (out of about 1.5K). The xlsx attached by Shaun is just one of them.

    The rest of the units are having a different location of memory corruption issue. One of them even has the BIM image location (which is located at page 1 of the internal flash) erased to FF.... Our code does not have a code line that is potentially can erase this BIM location.

    Regarding the large dip in Power, can I say that the MCU brownout voltage protection can protect against unwanted mcu behaviour. Could you enlighten me again why large dip in power could get issue on flash?

    Thank you

    Handi

  • 0 in reply to Handi Kartadihardja
    TI__Mastermind 18780 points
    What I meant was that if you get quick power dips within the allowed power supply range, you can get issues with the flash. But also, mechanical shock can impact the crystal frequency that can cause issues. This is only happening with mechanical shock, never without? Where is the chip in your application?
  • 0 in reply to CHS
    Intellectual 300 points

    HI CHS,

    Thank you. I am quite clear with mechanical shock might have impact on behavior of crystal frequency. It sounds logical.

    However, could you help to explain more why quick power dips "within allowed power supply range" could give issues on flash? Is there any reference or published experiment report that we can refer to strengthen the hypothesis?

    Thank you

    Handi

  • 0 in reply to Handi Kartadihardja
    TI__Guru** 105180 points
    Hello Handi,

    It would be helpful to identify if the corruption is happening in regions of the memory map that would not expect to be modified. To do this analysis, your map file details are required. Did you set any of the flash lock protection bits when the corruption occurred?

    I'm not aware of any published reports, but there are E2E threads where users have reported flash memory problems which were later found to be due to inadequate power supply conditions. It would also be helpful to know if your testing has uncovered any cases where any maximum ratings from the CC2541 data sheet have been exceeded, especially during a mechanical shock event.

    Best wishes
  • 0 in reply to JXS
    Intellectual 300 points
    Halo JXS,

    For temporary workaround, we are looking to enable the flash lock bit at certain pages, and disable the flash lock bit when CC2541 undergone Over-the-air update. Can you advise whether this approach is doable? can we enable and disable flash lock bit inside the running code?

    Thank you

    Handi
  • 0 in reply to CHS
    Prodigy 30 points
    Hi CHS,

    I am from the customer's team working on this issue on Firmware aspect.
    Could you please explain about "4 bytes within the Stack image for TX Calibration data"?
    Are these 4 bytes of calibration data written to flash? What is the purpose? When and how often are they written? Where is the code that does this writing, is it in the lib or in source? Can we disable? Can this writing cause flash corruption?

    You also mentioned "Normally flash issues are related to SW", could you please more details on that? If you have previous such case where SW causes the flash corruption issue, could you please share what scenario can trigger the flash corruption?

    Regards,
    Paramod
  • 0 in reply to Handi Kartadihardja
    Prodigy 30 points
    Hi CHS,

    I am from Customer's team working on this issue.
    Could you please provide more details on "4 bytes within the Stack image for TX Calibration data"? What this data is for? When it is being written and how often? Can we disable it and how? where is the code that does this writing? We do not use SNV.

    You mentioned "Normally flash issues are related to SW". Do you have any such case and in which scenario SW can trigger flash corruption? Based on the RMA units, the corruption is quite random, no fixed region or pattern of corruption.

    Also, please suggest Handi's question "can we enable and disable flash lock bit inside the running code?"

    Regards,
    Paramod
  • 0 in reply to Paramod Kumar
    Prodigy 30 points

    Hi CHS,

    I noticed that the lib (we use CC2541_BLE_peri.lib and CC254x_BLE_HCI_TL_None.lib) writes some data to SNV area too. Could you please suggest what those data are and where I can find the details?

    Is there any documents that details the lib?

    Can we get the lib source as i do not know how and when lib is accessing the flash and performing flash write. We commented all flash write in our application code, but the 4bytes for Tx power calibration and SNV area are still written which I suspect is being written by Lib.

    Also, shouldn't the lib save that 4bytes of TX power calibration data in SNV?

    Regards,

    Paramod

  • 0 in reply to Paramod Kumar
    TI__Guru** 105180 points
    Paramod,

    Aside from TX cal on first boot, the only writes to SNV is from GAP Bond Manager (included in source code). You can do a test by disabling GAP Bond Manager and defining NO_OSAL_SNV.

    Best wishes