• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 4 answers
  • Subscribers 83 subscribers
  • Views 719 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.

TMS320F2800137: Power not stable leads to Flash issue

Joyce Gao
Expert 3200 points

Part Number: TMS320F2800137

Hi expert,

We are using F2800137, and there are circumstances that hard to avoid that power supply fluctuates some time. And if the power supply fluctuates, the programming of the internal FLASH will meet errors, causing the software to fail to execute normally when the power is turned on again. Please help find out if there are any relevant solutions both HW and SW?

Many thanks,

Joyce

  • 0
    TI__Guru* 95315 points

    Joyce,

                There is no software solution to this issue. If the power stage is unable to supply the needed current during Erase/program (EP) operation, it will lead to unreliable programming. This is known behavior. In other words, if the device is current-starved during E/P, that may result in a failure. You could probe the power-supply pins during E/P to check if the voltage dips or if there is excessive ringing. The solution is twofold:

    Ensure the LDO (or DC-DC converter) used has adequate margin. i.e. it is able to meet both the steady-state and instantaneous power demands of not just the MCU, but the whole system. The decoupling is adequate enough, so that the voltage levels are steady (and within datasheet limits) throughout the E/P operation.

  • 0 in reply to Hareesh Janakiraman
    TI__Expert 3200 points

    Hi Hareesh,

    Thank you for the clear reply. First, we would like to add the detailed phenomenon and use case:

    We designed the system to write some sampled value into the Flash after power on. The LDO fluctuation in currently could not been avoided due to environment. Flash writing will fail in this case, and after power on again, the MCU could not run again. The only way to let the MCU run again is to download the program again using the debugger. For such phenomenon, we have a question:

    Why the MCU could not run again after power on/external reset again? If we could accept writing failure and giving another power on, is there any way to let the MCU run again by itself without downloading again the code using debugger?

    We also have question that:

    We enabled the BOR in the C2000 so suppose such UVLO/brown-out will trigger BOR. For this point, 

    If we disable the BOR, will it still be the same to cause the FLASH programming fail with the same fluctuating VDD? Asking this because we do not know the Flash issue relates only to the VDD or related to the reset process.

    Many thanks!

    Joyce

  • 0 in reply to Joyce Gao
    TI__Guru* 95315 points
    Joyce Gao said:
    Why the MCU could not run again after power on/external reset again? If we could accept writing failure and giving another power on, is there any way to let the MCU run again by itself without downloading again the code using debugger?

    When the device is current-starved during Flash E/P, it is very likely that the Flash is left in a corrupted state (partially erased/programmed, for example) at the instance of programming failure.

    Joyce Gao said:
    We enabled the BOR in the C2000 so suppose such UVLO/brown-out will trigger BOR.

    There are two issues here (1) The BOR threshold may be lower than the Vmin threshold. When teh supply voltage goes below Vmin, device is already operating in a out-of-spec condition, even before the BOR detection kicks in. (2) BOR may activate after the device is partially erased/programmed.

    Joyce Gao said:
    If we disable the BOR, will it still be the same to cause the FLASH programming fail with the same fluctuating VDD? Asking this because we do not know the Flash issue relates only to the VDD or related to the reset process.

    Both 1.2v and 3.3v supplies are critical to proper Flash E/P. 

  • 0 in reply to Hareesh Janakiraman
    Prodigy 30 points

    Hi Hareesh, thanks for your reply. 

    1. I saw the description about the issue in DS document: Brownout events during flash programming can corrupt flash data... My question is what cause the flash error, the very low supply voltage or brownout reset event? In fact, the brownout voltage is set about 2.95V, which should be able to meet right flash programming. So i guess the brownout reset event cause the flash error, not be low voltage. Please help to confirm. If the brownout event, disabling the brownout function may be one solution. Can the POR envent also cause the flash error if the supply voltage continue to decrease?

    2. After flash error, the DSP is in periodically reset. The reason should be the flash error will be found by ECC check and generate NMI, then NMI watchdog timer triggers the reset. My question is wheather the ECC check or NMI can be disabled to the DSP keep running. Besides, are there other better software method to clear the flash error and keep software running? To avoid the flash error, my method using is to minimize the flash programming operation and check the supply by software before programming.

  • 0 in reply to xiaoqing li
    TI__Guru* 95315 points

    For proper Flash programming, two things are extremely important. 

    1. The power-supply has sufficient current sourcing capacity (and adequate transient response) to meet the steady-state and instantaneous current demands of the MCU. You should not see any dip in the supply voltage during the entire programming process. In other words, the supply rails must always be within the limits shown in the datasheet (especially Vmin).
    2. The timing requirements for Erase/Program operations. This is taken care of when TI supplied tools are used.

    As mentioned before, the brownout threshold is likely lower than Vmin. Before that threshold is hit, device is likely already operating at voltages lower than VMIN. Disabling BOR or ECC check is not the solution since you will only be masking the issue. As I mentioned in my first reply, this issue must be adddressed in hardware, not software.

  • 0 in reply to Hareesh Janakiraman
    Prodigy 30 points

    Thanks for your reply.