• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 293 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28027: Parts become partially bricked after repeated bootloads

Todd Muir2
Prodigy 140 points
Part Number: TMS320F28027
Other Parts Discussed in Thread: C2000WARE

I am working on a project that uses the TMS320F28027 for motor control.  Another processor, running linux, interfaces with the f28027 via uart for the purposes of hi level control and firmware updates.  Our firmware update application had a bug where it would perform updates repeatedly, until something external stopped it.  When the process is killed, power to the f28027 is also removed.  This could happen anywhere in the update process.  On three or four devices, this has partially broken the processor.  The ROM bootloader can still run, but it will not run the second stage flash kernel written to it.  Also, the application in flash is either erased, or inaccessible.  Chips in this condition are also not able to connect to JTAG.  This is on a design that has had a few pcb revisions, and is otherwise fairly stable, as opposed to a one off prototype.  We are also using the recommended update procedure.  Other components being damaged on the board have been ruled out, as replacing just the f28027 solves this issue.  

Are there known issues with removing power during flash operations that would cause this situation where the chip is essentially bricked?

  • 0
    TI__Mastermind 38295 points

    Hi Todd,

    It is important for the F2802x device's power supply to remain stable during flash erase/programming. Removing power during these operations have the potential to corrupt flash sectors and permanently lock the device. See the below from the device datasheet:

    Best,

    Kevin

  • 0 in reply to Kevin Allen18
    Prodigy 140 points

    Hi Kevin,

    Thanks for the quick response.  Would this also cause the device to no longer be able to connect via JTAG?

  • 0 in reply to Todd Muir2
    TI__Mastermind 38295 points

    Hi Todd,

    Yes, a locked device can cause JTAG connection issues. One thing you can try is putting the device in WAIT boot mode and then try connecting, but if the passwords are set and unknown the device is permanently locked.

    See the below app report for additional details.

    https://www.ti.com/lit/spracf0

    Best,

    Kevin

  • 0
    Prodigy 140 points

    HI Kevin,

    If this is a known issue, what do other customers who use this device do to mitigate this issue?  Our device is powered through wall power, but just like anything else, it can be unplugged at any point by the user.

  • 0 in reply to Todd Muir2
    TI__Mastermind 38295 points

    Hi Todd,

    Are you frequently erasing and programming the device's flash during normal operation in your end application? Can you explain how you're using the operations? i.e. what & when you're programming and erasing the flash.

    It's best to prevent the device's power from being removed while in the middle of a flash erase / program operation to prevent a lock up like this.

    Best,

    Kevin

  • 0 in reply to Kevin Allen18
    Prodigy 140 points

    I don't intend to perform frequent firmware updates.  This issue was discovered because I had a bug in my logic for determining whether an update should be performed by the linux app on the host processor.  This was causing a loop where the update happened repeatedly, and the person testing the system killed the application performing the updates, which also killed the power to the f28027.  This logic will be revised to make this looping impossible, and also to decouple the power control from this app.   

    I use the flash kernel application that is provided in one of the SDKs.  First the ROM bootloader is run, and the flash kernel gets loaded to RAM.  Then the flash kernel runs, and my application gets loaded to flash.  I'm not super familiar with this particular bootloading process, but watching everything happen on a logic analyzer, I can see the timing. 

    The entire process, from when the ROM bootloader initial handshake occurs, to when the Flash Kernel has responded to the last commands sent, takes 8.5 seconds.

    Loading the flash kernel takes 1 second of serial traffic, followed by another second before the host processor attempts to handshake with the running flash kernel.  It looks like this second long wait is driven by the host processor, because the host transmits first at the end of this waiting period.  

    Next, a short burst of commands is followed by 2.5 seconds of inactivity, which I assume is the flash kernel erasing the flash.  

    Finally, it takes 4 seconds to write the application into flash.

    My guess is that during the time the ROM bootloader is running, there is no danger of damaging the flash due to a power cycle.  The danger zone stretches from the point the erase flash command is issued at 2 seconds, to the point the update is finished at 8.5 seconds.  Is that accurate?

    Are you saying that every customer that uses this device faces this risk every time they perform a firmware update?  The only mitigation is to keep updates as infrequent as possible?

  • 0 in reply to Todd Muir2
    Prodigy 140 points

    Hi Kevin,

    Can you point me to specific timing of flash programmings and erasings, as well as the Flash Kernels usage of them, and which sections of time are vulnerable to a power loss damaging the flash?

    We need to be able to minimize this period of vulnerability as much as possible.

  • 0 in reply to Todd Muir2
    TI__Mastermind 38295 points

    Hi Todd,

    Sorry about the delay in my reply.

    The timings for the flash program and erase functions are documented in the device datasheet. Note that these are typical times and that device's flash can experience longer times. See the FAQ topics at this link for more info on the device's flash as well: https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/757585

    Specifically the flash erase operation is the one to be careful of in case of a loss in power. You should ensure that power to the device is stable during the Flash Erase process to prevent the device from getting locked.

    If you have C2000WARE installed, you can find additional details on the Flash API functions and usage in the directory below:

    C:\ti\c2000\C2000Ware_3_02_00_00\libraries\flash_api\f2802x\docs\Flash2802x_API_Quickstart.pdf

    Best,

    Kevin

  • 0 in reply to Kevin Allen18
    TI__Mastermind 38295 points

    Hi Todd,

    I'd like to add some more information that may be helpful. The flash sectors of the F2802x device are balanced, as described in the older post below:

    https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/111828

    On F2802x specifically the sectors are balanced as below:

    Sectors A and D are balanced.
    Sectors B and C are balanced.

    Maybe an option for you is to only use sectors B and C for firmware updates to prevent the device from getting locked, i.e. sector A includes the security passwords.

    Best,

    Kevin