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.

CC2530: CC2530 flash corruption

Part Number: CC2530

Hi,

I am working on devices that appears to have a problem very similar to that one:

The topic referred above is locked, and there is no mention of any solution.

We are using OSAL NV service that manages 6 Flash pages for storage, and we can observe at least one word in an other page to be overwritten, leading the code to malfunction.

The hal code to access the Flash is old (2010) and possibly not compliant with CC2530 datasheet. As for an exemple, datasheet recommends to erase a page with under critical section, whereas the code from hal_flash.c does not.

Are there any update of this code or know issues.

Many thanks.

  • Hi laurent,

    The previous threads involved hardware issues (undervoltage, ESD) whereas you are indicating a software bug (hal flash access). Are you using an EVM or custom board? Does the issue occur if using software provided by TI? Are you running a Zigbee stack/application? Can the issue be replicated on any unit or only some ICs?

    Regards,
    Ryan
  • This thread can help you. There is hardware problem which cause flash write problems.

    e2e.ti.com/.../530300
  • Ryan,
    the previous thread was also about word erased outside of expected range, this is the way our problems are similar.
    The board is custom. Two devices failed on the field (power outage might have occur), one device failed in the lab trying to reproduce, other devices are currently under test.
    The software runs a TI ZigBee pro stack, and OSAL_NV is the only caller to HalXxxFlash functions.
  • Aleksandar,

    Thank you for sharing this very interesting thread.
    It has a lot of changes, and I will probably consider to split them in piece before giving priority tho test:
    * checking FCTL for busy bit is definitively a must have.
    * the dummy DMA transfer is a big hammer, but sounds meaningful.
    * check vdd ... why not ? I can't believe that this could be the cause of my issue, but i'll definitively try, at least in Debug builds.
    I never encountered flash corruption in the area reserved for NV data, my issue is that bits have been erased outside.

  • We have a lot of interesting things going on here in this thread.
    I'm the owner of the post quoted by Laurentz.

    I'm trying to follow every post related to Flash Corruption. People are reaching me trough personal messages to discuss about corruption events.

    Ryan Brown1 (3460875)
    From my understanding, Laurentz is also having flash corruption events. He has raised a question regarding the "hal_flash.c" library available in ZSTACK that is different from the recommended code presented in CC2530 Datasheet.
    The code in the datasheet disables the global interrupts while ZSTACK doesn't.

    So now we have a lot of complains from different users regarding flash corruption and to sum up, now we have a potential failure in the chip's DMA.
    Since you can't write the flash without using DMA, these problems are related.

    Texas is avoiding this problem since 2016. This is a real issue with a considerable number of cases but nothing is being done about this.

    Aleksandar Majdak34 (3607697)
    Could you please provide more information about your case? What motivated you to modify the HalFlashWrite() function?
    How did you realize there was a problem in the DMA in first place?
    Can you please tell us which tests have you made and the conclusions you've got?

    @TI Employees

    Do not close threads that are not completely answered. You are making difficult for us users to find answers within the forum and to follow related subjects.

  • Hi Alessandro,

    I can assure you that TI does not mean to avoid this problem, nor have we closed this thread or others related to it. I was waiting for laurent to comment on the effect of the changes recommended by Aleksandar or implement the flash procedure from the User's Guide. I am trying to include an employee who might know more about this issue.

    Regards,
    Ryan
  • Hi Ryan,

    I don't want to steal Laurent's thread, but please take a look at the threads below:

    https://e2e.ti.com/support/wireless_connectivity/zigbee_6lowpan_802-15-4_mac/f/158/t/634787

    https://e2e.ti.com/support/wireless_connectivity/zigbee_6lowpan_802-15-4_mac/f/158/t/560246#pi319568=1

    Can you tell me why they were closed? Can you see how hard was to get an answer on these threads? None of Texas recommendations worked out and Ta12012 sent me a personal message to inform that he will look at this problem closely. This was in October, but we are in march and Texas has just requested me some of my defective boards to analyse. I'm arranging the shipment, but how long does this analysis will take? What is the priority? What should I do while there is no solution? There is no formal ticket assignment to follow and there is no official workaround. Aleksandar has pointed out a problem and nobody asked for details. By all the above statements I understand that TI is avoiding the problem.

    I really want to be wrong, but at the end I really think this whole flash corruption and DMA concerns will generate an errata, but this SoC could be obsolete by then.

    Fortunately you are replying to this thread regularly.

  • Ryan,

    we are currently doing test partially based on Aleksandar recommendations, as I explained in my answer his post.

    I was in the hope that TI is aware of such issues and can make educated recommendations based on their knowledge of the hardware.

    --

    Laurent

  • Hello Alessandro, Laurent,

    I apologize for the delay, this is still being investigated internally.

    Regards,
    Ryan
  • We also continue to investigate. Progress are very slow because it is not easy to reproduce and detect.

  • I'm closing this thread due to inactivity. Please free to reopen this thread by replying.

  • I am sorry TER, but the issue is not resolved and the last two messages before yours, including one TI staff said that the issue is still under investigation.

    TI cannot close this thread, while alleging to continue investigations.

  • Still under investigation