• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 82 subscribers
  • Views 366 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.

Original question:

TMS320F28377D: Is there a setting to prevent destruction due to power off when writing?

TMS320F28377D: Software and circuitry to protect against power failures during write operations.

K.Z
Genius 3215 points

Part Number: TMS320F28377D

Tool/software:

Hi All,

Do you know how to develop software and protection circuits that can protect against power failure during write operations?

Best Regards,

Ito

  • 0
    TI__Mastermind 45606 points

    Hi Ito-san,

    You are meaning specifically when performing flash programming writes? Or something else? And by power failure are you meaning the power rails dropping too low (i.e. outside of the device specs)?

    SW wise, limiting the size of programming runs and checking voltage rails (using ADC) in-between each write could help.

    App note here has some HW suggestions: https://www.ti.com/lit/slva833

    Best,

    Kevin

  • 0 in reply to Kevin Allen18
    Genius 3215 points

    Hi Kevin.

    Thank you for your reply.

    The original question is here.

    https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1510344/tms320f28377d-is-there-a-setting-to-prevent-destruction-due-to-power-off-when-writing 


    A customer turned off the power during a Flash write in CCS, destroying the MCU.

    We are trying to develop external protection circuits and software to prevent this.
    Do you have any suggestions for countermeasures?

    Best Regards,

    Ito

  • +1 in reply to K.Z
    TI__Mastermind 45606 points

    Hi Ito-san,

    For power-off hardware protection circuits, that app note I shared (slva833) has some discussion in sections 8-10. However it primarily discusses a short power interruption time, not a continuous power off condition. You can have some bulk capacitance to power the system for a short time to complete any flash programming process, that's all I can think of.

    I will pull in some other experts to see if they have other HW / SW suggestions.

    Best,

    Kevin

  • 0 in reply to Kevin Allen18
    Genius 3215 points

    Hi Kevin.

    When the customer was rewriting the program for the end product,
    there was a power outage during the rewriting process, which seems to have caused a malfunction.
    It seems difficult to pay attention to power outages in an environment where they are likely to occur.

    Bulk capacitance can handle short power outages,
    but I don't think it can handle long power outages such as during writing.

    Do you know of any HW/SW countermeasures?

    If this issue is not resolved, it may be difficult to adopt TI products in the future.

    Best Regards,

    Ito

  • 0 in reply to K.Z
    TI__Guru* 85270 points

     Ito-san,

    One idea would be if an external supervisor had a warning type limit, that could be used to set a GPIO on the C2000 in case of unexpected fluctuation of the power supply.  The C2000 could check this during flash operation, we have set points in the API that can be used to service ISRs, etc, and if this signal goes high we could take steps to pause the programming until the event is cleared.

    There are, however, certain un-interruptible portions of the flash API, if the droop occurs during these times there is not much we can do.  Even forcing XRSn active during this time is not recommended to make sure the flash is not impacted.

    I believe the solution is as Kevin originally mentioned, along with some knowledge of the environment and what kind of power events are possible and restricting programming to X words/time before checking to see if the power is still good.

    I am curious if we see competition offer this kind of protection, and understanding how they are accomplishing it.

    Also, one of the main issues we saw on previous generation of products was the flash getting locked during programming interruption.  On these Gen 3 devices, the CSM passwords are moved to OTP, so the chance of lock should be lower, do we have any additional info on the what failed on the C2000 after the power event?  Was the flash depleted, etc?

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Genius 3215 points

    Hi Matthew,

    Thank you for your reply.

    After the power failure, the following conditions occurred.
    ・Unable to write the program again
    ・Program does not run

    For this reason, we cannot check the contents of the MCU.
    We suspect that the flash memory is faulty.

    We confirmed your proposal with the customer, but they do not have the technology to design this.

    Please tell us specifically what actions we should take to resolve this issue.
    I do not know how our competitors are handling this.
    It would be helpful if we could refer to information about our competitors...

    I particularly do not understand the following comment.

    MatthewPate said:
    I believe the solution is as Kevin originally mentioned, along with some knowledge of the environment and what kind of power events are possible and restricting programming to X words/time before checking to see if the power is still good.

    Best Regards,

    Ito

  • +1 in reply to K.Z
    TI__Guru* 85270 points

    Ito-san,

    The device cannot tolerate power faults/interruptions during the flash erase or program times.  This is a limitation of our flash technology.

    By only erasing/programming smaller regions at a time, and then checking the state of the VDDIO supply with the ADC, we can attempt to limit the chance that we have a power fault during the flash program time.

    My last statement was more to the customer's end application and its mission profile.  If there is any conditions that customer would expect more frequent power interruptions, then we should try and avoid those for programming the device.  If we are saying there could be power faults at any time randomly, then the above mitigation will be our best soln; but we have no other on-chip mechanisms in HW to prevent this from happening.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Genius 3215 points

    Hi Matthew-san,

    We will create our own program to write to flash memory,
    monitor the power supply with an ADC, and
    take measures to stop the program when a voltage drop is detected.

    Does memory become abnormal only when the power is cut off during flash erasure or writing?
    Are there any other possible factors?

    Also, I think the program will wait while checking the flag during flash writing or erasure.
    Is there a program interruption command that can be executed when the power off at this time?

    Best Regards,

    Ito

  • +1 in reply to K.Z
    TI__Guru* 85270 points

    KZ,

    K.Z said:
    Does memory become abnormal only when the power is cut off during flash erasure or writing?
    Are there any other possible factors?

    If the operation is interrupted by external means for any reason it is problematic.  So, for example, if there is an external supervisor that will pull XRSn low asynchronously, that could be problematic.  The flash API itself is interruptible, but care should be taken with modules like the Watchdog or NMI Watchdog that they create an ISR event and not an automatic reset if they time out.

    K.Z said:
    Also, I think the program will wait while checking the flag during flash writing or erasure.
    Is there a program interruption command that can be executed when the power off at this time?

    The Flash API on this device is interruptible; the only restriction is that code must be ran from RAM while the flash is being programmed/erased.  During an erase or program operation, that needs to complete before the device is reset, etc.   I think the best approach is to do smaller updates to limit the time the flag will be inactive.

    Best,

    Matthew