• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 434 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.

TMS320F28075: Unexpected ECC faults.

Corey Paye
Prodigy 40 points

Part Number: TMS320F28075

Hello,

We are using a TMS320F28075 DSP in a device.  The ECC check is enabled for the flash memory.  As per the errata the error threshold is set to > 0.  (In our case it was being set to 1.).  The application regularly checks for UNC_ERR_INTFLG (uncorrectable error interrupt flag) and the ERR_CNT (ECC error count).  If either the UNC_ERR_INTFLG is set or if the ERR_CNT is greater than 0, the system signals a fault to the user and forces them to do a system reset.  Over many, many hours of testing using dozens of different devices, this has only occurred a few times.  However, it has come up a few times recently as we finalize the design and it has been difficult to correlate these faults with a root cause.  According to the lead developer, when the fault is detected, the application is not writing to flash.  For the near term, based on information in the reference manual, we are going to increase the error threshold to a much larger value.  However, we would like to get a better understanding of the root cause. 

My initial questions are this:

  1. What is the best reference for understanding how the  flash ECC works?  (I have not used devices with ECC and so I am not very familiar with the technology.  I’ve read relevant sections in the DSP reference manual and some other notes but if there was a clearer high-level picture that would be helpful.)
  2. Have you heard of this issue with other DSP users?
  3. The application does not use the OTP space but it does use the emulated EEPROM feature.  Could this have an effect?

Thank you.

  • 0
    TI__Guru* 87155 points

    Hi Corey,

    How many write/erase cycles did you do for the emulated EEPROM sectors?  Hope it is with in the datasheet spec limit.

    Did you observed that on multiple devices or one device?

    Is the error address reflecting your application code space or the EEPROM sectors?  If it is only in the EEPROM area, it might be that the ECC is not programmed correctly.  Based on the address at which the error occurred, did you check whether or not the ECC is programmed correctly at that address?  

    Do you use Fapi_AutoEccGeneration mode for programming? This mode calculates the ECC and programs it along with the data.

    1. Apart from TRM's flash chapter's SECDED section, we don't have any other diagrams.  If you have any specific questions, we can help answer them and enhance the TRM accordingly.

    Below are couple of FAQs that can help debug:

    FAQ on Flash API usage for C2000 devices:   https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/951668 

    FAQ for Flash ECC usage in C2000 devices :  https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/951658 

    2. No, we did not.

    3. It can be that the ECC is programmed incorrectly.  Hence I asked above questions.  

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    Prodigy 40 points

    Vamsi,

    Thank you for the quick reply.

    I see in the datasheet that flash is spec'd at a maximum of 20,000 erase cycles.  It is unlikely that we are exceeding this in our testing.  Do you have approximate values for the minimum and standard?

    This has happened on multiple devices but has been very rare (however I am not sure of the percentage).  

    We have not checked the specific address.  This is a very good suggestion.  I will ask the lead developer about doing this.

    Fapi_AutoEccGeneration mode is being used when an EEPROM write is performed.  

    I should add that these faults have occurred randomly during operation -  they do not occur immediately at start-up or at specific points in application execution.  

  • 0 in reply to Corey Paye
    TI__Guru* 87155 points

    Corey,

    How many sectors are you using for EEPROM emulation?  

    If it happened on multiple devices, I am very sure that it can be your SW problem.

    Please check the address and debug from there.

    Reason for random can be that: It depends on when the application reads the incorrectly programmed locations - it depends on the input conditions of your application.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    Prodigy 40 points

    Hello Vamsi,

    We are using three sectors for the EEPROM emulation (sectors C - E inclusive). There are empty sectors on either side of this range to guard against corruption of the application or other data.

  • +1 in reply to Corey Paye
    TI__Guru* 87155 points

    Hi Corey,

    Ok, if you are using 3 sectors and with in the spec W/E endurance limit, then that should not be a flash memory issue.
    Please debug based on the error address and trace back.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    Prodigy 40 points

    Hi Vamsi,

    Ok, thank you for confirming that.  We have a workaround that we are hopeful will address this issue.  We will not be able to confirm which address is triggering the issue for a while due to the point we are at in our testing but I will mark your response as resolving this issue to close things out because I think what you are suggesting is the right next step.

  • 0 in reply to Corey Paye
    TI__Guru* 87155 points

    Corey,

    Thank you for the update. You are in the right direction. I will close this thread now. If you have further questions, you can open a new post if this thread gets locked.

    Thanks and regards,
    Vamsi