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.

TM4C1231H6PZ ROM bootloader failure

Other Parts Discussed in Thread: LMFLASHPROGRAMMER

Hi, 

This is the first time I post a message on this forum but I have been here may times and have to say that it is an invaluable resource when in trouble. Most likely somebody else has run into the same problems before but that is not the case now. 

Here is the situation:

Two custom boards we designed using TM4C1231H6PZI microcontroller and used for several months to develop the firmware without a glitch have failed in the same way within a few hours while attempting a firmware update: microcontrollers fail to boot and can no longer be accessed, either thru JTAG or SWD interface.
While I am not ruling out the possibility that we did something wrong I cannot seem to figure out what has happened. As a side note, new boards were programmed with the same fw update and nothing happened to them.

Assuming it might have been accidentally locked, I have tried unlocking it from LM Flash Programmer with no success.

Further hardware investigation revealed that the JTAG/TDO line is toggling (for the record, at ~13Hz ) as it is mentioned in the datasheet at page 204:

Note: If the device fails the initialization phase, it toggles the TDO output pin as an indication the
device is not executing. This feature is provided for debug purposes.

I have run out of ideas and could not find anything related to this problem on this forum after a few hours of searching.

Before anybody questions it, all hardware is OK, I have replaced the chip on one of them and all hardware is working just fine.

Any ideas? Thank you, Daniel

  • Hello Daniel

    Rather unfortunate for device to have locked up.

    1. When using the LMFlashProgrammer, it requires ICDI (one can be salvaged from a LaunchPad or older LM3S EVM's) for the Unlock operation

    2. Was the code using EEPROM (it has a known errata for device lock out)?

    Regards
    Amit
  • Hi Amit,

    Thank you for your quick reply. I did use a launchpad with LM Flash Programmer to attempt the unlock, but with no success as I said. I have tried several times, still locked.

    The code is using the EEPROM but the errata does not apply in my opinion, power was not interrupted as far as I can tell. Unfortunately I do not know what happened. Just trying a fw update and device won't boot anymore. But two times in a short period of time? That is true , with units that have been programmed probably thousands of times.

    Unless I missed it, MEM#04 and MEM#05 are the only known issues to render the device non-functional in the errata document.  Again, although I do not think it applies, whatever happened,  it happened during a fw update, reading the errata again I am bit puzzled by one of the workaround solutions:

    MEM#04  workaround(s):  ....Limit the number of lifetime EEPROM writes to 7 writes per word.  .....


    Does this affect the program/erase cycles specs of 500K cycles? Now I am worried!

    Thank you, Daniel

  • Hello Daniel,

    EEPROM program/erase when interrupted by a reset or power cycle may cause the issue. Since this is a very random effect, it is tough to predict its occurrence. As you mentioned that this happened after 1000's of program/erase cycles it can lead the EEPROM more susceptible.

    The correct approach would be to send it back to TI for FA and we can confirm if indeed the issue is because of the EEPROM.

    Since you have already tried the Unlock Sequence with a LP, there is nothing more that you can do at this point other than to send the device back to TI or replace it on the system.

    Regarding the WA, the use of EEPROM to max of 7 will limit it's 500K cycle. However "not to worry". It is important to guarantee that the Program/Erase of EEPROM must not be interrupted. There are 2 ways

    1. Switch to Rev-7 which has the fix
    2. If an EEPROM is ongoing then ensure that all possible sources of internal interrupts (invoked by a firmware update) or reset (disable WDT) are disabled while the operation of EEPROM is going on. This will reduce the probability of occurrence,

    Regards
    Amit
  • Hi Amit,

    1. I got that, there is nothing I can do, I already tried everything I could.

    2. Although the chips were subject to thousands of flash erase/program cycles, the EEPROM was NOT, and the 2 chips failed quite at the same time. Maybe TI should recheck that endurance specs for both the flash and EEPROM because I am not sure the EEPROM write is the culprit.

    2. Since external programming is asynchronous to the running code, I agree with you that he chance of getting into the conditions of errata MEM#04 is real if the code is writing to EEPROM on a regular basis - EEPROM write might be happening when programmer tries to get control of the target but still too weird that 2 units failed within few hours. Keeping the writes to EEPROM under strict control is not a problem under normal operation with no external programming.

    3. This is quite a serious issue with this microcontroller since it can be rendered non functional if a power loss happens while a write to EEPROM is performing.  I find it very weird that nobody posted anything about this until me. But I guess is just a mater of probability, we do have to write to EEPROM fairly often and that increases the chance to get into the issue MEM#04. This is the only run-time errata issue that can make the chip non functional, shouldn't be at the top of the list? Maybe a ranking of these errata issues is a good thing to implement in the future. Good luck with that!

    4. Hopping that this was fixed in rev 7 and affects only rev 6 as the errata says, although not sure that is indeed resolved, until it pops up again, we will use only rev 7 or  newer (in the future) for production. However, rev 7, so far,  is not available yet at any distributors, I checked. When do you think is gonna be available?

    5. Can TI send me some rev 7 chips to test before they become available at the distributors?

    6. Can you advise how I return these 2 damaged chips to TI for further analysis?

    7. Just out of curiosity, how the design team came up with this number 7 as the maximum lifetime writes to EEPROM to circumvent the issue of MEM#04? It makes no sense to me and it should be deleted from the errata. Maybe more detail was needed but as it is stated is frankly wrong and makes me "take all the documentation with a spoon of salt".

    Thank you,

    Daniel

  • Hello Daniel,

    During simulated power testing we could multiple devices to fail, so it is not surprising that devices may have failed close to each other in time. The post has come up a few times on the forum (since I have replied to the issue in the past). The issue has been fixed in rev-7 for sure (as that was the change we had to make)
    If you have procured the parts through Distribution, then you can submit the parts back to them for return for Failure Analysis. However I am not sure if we or distributor can provide rev-7 samples instead.

    The number 7 is based on the structure of the EEPROM. This is mentioned in the datasheet for EEPROM operation.

    Regards
    Amit