• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 540 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.

TM4C1231D5PZ: TM4C1231D5PZEIR PowerUp issue resulting in locked-up MCU or MCU w/ entire Flash erased..

Newman
Expert 5995 points
Part Number: TM4C1231D5PZ

Hello Team TM4C,

My customer has been in-production for several years w/ the TM4C1231D5PZEIR MCU w/ generally good results to date..  But, recently during life-test, they have run into an issue..

 The customer board, after having been automatically cycling for many days (as part of a life-test), was found to be in a state where the MCU appeared to be non-functional:

a)      All MCU outputs appeared to be in a high-impedance state

b)      The MCU was no longer communicating serially (UART serial communication)

c)       It appeared like the TM4C1231D5PZEIR was in a RESET state permanently.

d)      They tried a forced a hardware reset and confirmed the MCU reset pin transitioned from 3.3V to 0V & back to 3.3V.  However this hardware RESET had no effect on the MCU.

e)      The only way to get out of this condition was to completely disconnect power to the board, then power it back up.

f)       Once power was cycled one of two things was found:

-either the board would work normally again or

-the board no longer functioned (in this case, upon investigation, the entire firmware had been erased).

g)       This behavior has been observed many times.

Other TM4C designs are in production but the only issue seems to be w/ this device (TM4C1231D5PZEIR) on the one board.

My customer had a look at the errata (http://www.ti.com/lit/spmz849 ) and did not find anything of note.  Errata MEM#05 is consistent with the observed behavior but they think it’s not applicable to their use-case.

I asked them about a potential bootloader issue since I saw this (possibly applicable) forum post.. https://e2e.ti.com/support/archive/internal/int-stellaris_arm/f/176/t/412734 .

Thanks, Merril

  • 0
    TI__Guru*** 135355 points
    Hello Merril,

    Is this just a single failure from a large production run?

    If they re-flash the device with the proper firmware, are they still able to recreate the behavior on the failed device when power-cycling?

    I agree with their assessment on errata items, MEM#05 is the primary one that stands out to me. I think the boot loader question is a good one, but if the failure is isolated to one board and occurs after re-flashing firmware, I would then expect a boot loader issue to be more widespread among their products.

    Depending on the answers, an FA may be the best option here. The behavior described of the flash being erased makes me suspect the part may be defective.
  • 0 in reply to Ralph Jacobi
    TI__Prodigy 350 points

    Hi Ralph,

    Here are the answers to your question above:

    - This is not a single failure.  We have seen this on approximately 15 boards, from multiple production runs.

    - Yes the customer is able to recreate the behavior.  Although they create it by running cycles on the machine, not by power cycling.

    “Proper Firmware” – We have not seen this condition on our production firmware.  Only on development firmware.  Although that doesn’t explain why the hardware reset pin doesn’t seem to have an effect.  Or why the control firmware has been erased.

    Thanks,

    Zack

  • 0 in reply to Zack Schwarz
    TI__Guru*** 135355 points
    Hello Zack,

    I have been looking to see about anything related to this but I haven't come up with anything similar occurring in the past. At this point while I understand the resulting symptoms of the issue well, I don't have much information beyond that to look in more detail.

    The customer has said this is occurring only on development firmware, so from that side a few questions:
    1) Is this a brand new project or updates to an existing project?
    2) If updates to an existing project, what has been changed?
    3) If brand new, what peripherals are being used? Is a boot loader being used?
    4) Are there any API's within the code that resolve around modifying the Flash memory after programming?

    Are the boards they are using also new? If so, from a hardware standpoint, if it's recreateable, can they test if the issue follows the device or stays isolated to specific boards? I.E. do an ABBA test with a working board and a board that exhibits the failure.
  • 0
    Guru 92251 points

    Newman said:
    -the board no longer functioned (in this case, upon investigation, the entire firmware had been erased).

    Zack Schwarz said:
    “Proper Firmware” – We have not seen this condition on our production firmware.  Only on development firmware.  Although that doesn’t explain why the hardware reset pin doesn’t seem to have an effect.  Or why the control firmware has been erased.

    Does the development firmware perform a write to flash while running in flash?

    If so, might be affected by errata MEM#14 Flash Write Operation During Execute from Flash may Result in Wrong Instruction Fetch.

    Possible TM4C123 hardware bug was the original investigation which led to errata MEM#14 being raised, and one failure mechanism seen was that the first 1K page of flash (address 0x0 to 0x3ff which contains the interrupt vectors and part of the program) had been erased.

  • 0 in reply to Zack Schwarz
    TI__Guru*** 135355 points
    Hello Zack and Merril,

    Any updates on this issue?
  • 0
    TI__Guru*** 135355 points
    Hi Merril,

    As we've had to exchange some key pieces of information offline, lets close this thread for now. I can update here when we get a solution if its useful for the community.