• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 612 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.

TMS320F28377D-Q1: Failure chip: sector 10 Flash contents and its ECC value will change automatically?

Will Gao
Intellectual 2335 points

Part Number: TMS320F28377D-Q1

Hi BU, 

Customer side found chips that always reset, from our debug, we found it is caused by Flash uncorrectable error and the error address is located at sector 10. This sector is used to store a table. I read this region by emulator, and at the same time the CPU1 is stopping at NMI ISR, and I also stopped the CPU2. But strange thing is the Flash content in this region will change in this situation (in the memory browser window, we can see some red value which means that the value is changing). Furthermore, we checked the corresponding ECC region, and found that it is also changing. The emulator is fine because we connect it to another normal board, the value is not changing. 

Please give your insight about this issue. Do you recommend to do Failure analysis? Thanks. 

BR, 

Will 

  • 0
    TI__Guru* 82670 points

    Will,

    From your data it appears that the flash in sector 10 is not reading back data consistently.  Can you verify that the waitstate setting is correct for the system clock in the customer system?  If you see this is correct, can we try to increase the WS to see if the data becomes stable, just as an experiment?

    If this has no effect(or we need >> more WS than required to get good results), then I agree that the data in the flash either wasn't programmed correctly or there is some issue with the CPU reading data from this region.

    Do we know this is only happening to sector 10, and on multiple devices?  Is Sector 10 programmed differently than the other sectors, meaning is it programmed separately from the rest of the code, etc?

    Table below:

    FRDCNTL, where WS are set

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Intellectual 2335 points

    Hi Matthew, 

    Thanks for your instruction. I will let customer modify the RWAIT parameter via emulator and try if similar issue happen. 

    MatthewPate said:
    Do we know this is only happening to sector 10, and on multiple devices?  Is Sector 10 programmed differently than the other sectors, meaning is it programmed separately from the rest of the code, etc?

    Yes, Sector 10 is programmed separately from rest of the code. And I've checked the programming codes for sector 10, it should be fine. 

    From my debug, this is only happening to sector 10, other sectors/ECC are fine. 

    Regards, 

    Will 

  • 0 in reply to MatthewPate
    TI__Intellectual 2335 points

    Hi Matthew, 

    Customer tried to increase the RWAIT parameter but no effect. The Flash content and ECC value are still changing. Any other possibilities for this phenomenon? For example, power supply for Flash? Please help. 

    Best, 

    Will  

  • 0 in reply to MatthewPate
    TI__Intellectual 2335 points

    Hi Matthew, 

    From my understanding, it maybe caused by unstable state for Flash memory cell, so that the bit-value identification result may change. Am I right? Because after re-erasing or re-programming the device, this issue will not happen anymore. 

    If it is true, can Failure Analysis (FA) analyze this? 

    Best, 

    Will 

  • 0 in reply to Will Gao
    TI__Guru* 82670 points

    Will,

    I agree with the initial assessment that the flash bit(s) were not fully programmed if they begin changing state.  Do we know the time after initial programming customer began to observed flash contents changing? 

    Since the device can be programmed it sounds like charge loss over time; even if flash has been re-programmed correctly I would think it would fail again.  I think sending back for FA is the correct path here; we may see an incorrect voltage even after recent re-programming as well as we could wait to see if it moves(if customer can provide that info).

    Best,
    Matthew

  • 0 in reply to MatthewPate
    TI__Intellectual 2335 points

    Hi Matthew, 

    Thanks for the answer. Have already recommended customer to send the chips back and do FA. 

    Best, 

    Will