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.

TM4C129ENCZAD: Device not waking from hibernation

Part Number: TM4C129ENCZAD

Hello,

We are using TM4C129ENCZAD in a released product for a couple of years now, and the released product uses hibernation mode.  Lately, we have seen a few devices coming off of our manufacturing line that will not wake up from hibernation mode.  I can provide mode details if needed but here is a short summary of the issue we are seeing:

  1. The device powers up and enters hibernation mode with hibernation wake up set to HIBERNATE_WAKE_PIN
  2. We verify HIB pin is asserted in this state
  3. We press a button that asserts WAKE pin
  4. We see HIB pin gets de-asserted which enables our VDD regulator
  5. ~1 ms after HIB pin gets de-asserted, VDD is stable at ~3.3V
  6. At this point, it seems like our code does not get executed

The first couple of lines of our code enable a GPIO output, set the output to 1 and wait for ~500 ms before clearing the GPIO output (the GPIO output drive an LED to indicate the device is "alive").  In step 1, we can see this happening.  But after step 5, we do not see this happen.  Its almost like the TIVA part itself is not coming out of reset after step 5.  Has anyone seen anything like this?  Is there something else we should check?

Note that this has now happened on 4 devices out of hundreds so it does not happen often.

Any help or guidance would be appreciated.

Thanks,

Mitch

  • Hi Mitch,

      Can you find out the date code from these 4 units? I'm not sure if you are hitting the below errata. If you press the reset, does the device wakeup to execute?

  • Hi Charles,

    We saw that errata yesterday as well and checked the data codes on these devices and they are 0x7A, (October, 2017) so they are not parts affected by that errata.  We also just tried asserting the reset pin when the device is in that state and that doesn't wake up the device either.  Could there be something wrong with these TM4C129 parts?

    Thanks,

    Mitch

  • Hi Mitch,

      I guess the VDD is good from your regulator, correct? I have some questions. 

      Can you connect to the device? 

      What is the VDDC (1.2V) voltage? Can you measure it? 

      For experimental purpose, can you keep the VDD always ON? 

      If the debugger can connect to the device, can you erase the part and load some simple example such as the blinky or the hello example?

      Is this the same firmware that have been programmed to your products since 2017? Is there any change to the firmware recently? 

      Is this the same board since 2017? Is there any changes to to board recently? I'm not sure if the devices have experienced an EOS (electrical overstress).  

      

      

  • Hi Charles,

    Here are the answers to your questions:

    1. Can you connect to the device?
      • If you mean with a debugger, then yes we can connect to it.  Not while it is in hibernate state but after we wake it up from hibernate and the processor doesn't seem to do anything, we can connect at that point.  I am able to connect to it and if I just load the symbols instead of loading the program (i.e. connect JTAG to a running device), I can see that the PC appears to be 0x010019a4 which doesn't seem to valid, and it says "no symbols are defined".  I'm not sure if we can trust that when the device is in this state though.

    2. What is the VDDC (1.2V) voltage? Can you measure it? 
      • In hibernation mode it is 0V.  When we wake up from hibernate and see this issue. we measured it at 1.198V.
    3. For experimental purpose, can you keep the VDD always ON?
      • We did this experiment and observe the same behavior even if we keep VDD on during hibernation.
    4. If the debugger can connect to the device, can you erase the part and load some simple example such as the blinky or the hello example?
      • I am able to load our full application, and I can skip the hibernation mode from happening and just boot up the device immediately every time, and that works fine.  Basically, if I take hibernation out of the equation of our application, then it works just fine.
    5. Is this the same firmware that have been programmed to your products since 2017? Is there any change to the firmware recently?
      • The firmware has changed a few times over the years.  But we can take a device that has this issue and install any of the FW versions we have used since 2017 and the device still has the issue.  And devices that work fine will work with all of the versions of FW we have used since 2017.  So the issue tracks the HW, not the FW.
    6. Is this the same board since 2017? Is there any changes to to board recently? I'm not sure if the devices have experienced an EOS (electrical overstress).
      • We have been using this version of the board since November 2018 and haven't seen this issue until the last week or 2.

    Thanks,

    Mitch

  • Hi Mitch,

      Earlier you were saying the device seems to not come out of reset after step 5. But from your replies to the six questions the device seems to be functional except the hibernate mode. 

      Can you run the TivaWare hibernate example on both the good and the bad units? Do they show different results?

    Mitch Mandler said:
    But we can take a device that has this issue and install any of the FW versions we have used since 2017 and the device still has the issue.  And devices that work fine will work with all of the versions of FW we have used since 2017.  So the issue tracks the HW, not the FW.

    I agree this is a HW issue. There are some more experiments I can think of  to perform. Can you swap in a good device into the bad board and swap a bad device into a known good board. I want to make sure it is not a board level issue. For example, do you have the 32.768k OSC running correctly?  

  • Hi Charles,

    Earlier you were saying the device seems to not come out of reset after step 5. But from your replies to the six questions the device seems to be functional except the hibernate mode. 

    These "bad" devices do seem fully functional except for exiting hibernation mode.  If I skip hibernation mode altogether on the "bad" devices, then I don't see any issues with the device (note that we can enable a setting on the device that will bypass hibernation mode if the device is plugged in).  Maybe my initial description of the issue was not clear and sorry for the confusion but everything works fine, except when we wake up from hibernation, it appears to me that none of our code gets executed at that point.  I said it seems like the device is not coming out of reset mode at that point because we don't see our code execute, but we are not really sure what is going on at that point.

    Can you run the TivaWare hibernate example on both the good and the bad units? Do they show different results

    I spent some time trying this out but it seems like those projects are targeted for specific evaluation boards or something like that.  And I couldn't get them to work correctly on our boards (I kept getting faults).  It would probably take a lot of effort to get this working on our actual HW so I won't be able to do that right now.  In the mean time though, I have already done this test with our hibernate code and the "bad" units are never able to exit hibernation mode properly while good units have no problems exiting hibernation mode.

    I agree this is a HW issue. There are some more experiments I can think of  to perform. Can you swap in a good device into the bad board and swap a bad device into a known good board

    We sent one of the boards back to our board manufacturer today to swap the TIVA part with a different one.  We expect to get that board back from them early next week and I can let you know the results of that test next week.

    I want to make sure it is not a board level issue. For example, do you have the 32.768k OSC running correctly?

    Yeah, we verified the OSC is running correctly yesterday before submitting this question to the forum.

    I am going to put this on the back burner for now until we get the result from swapping the "bad" part with a new one.  It seems like this doesn't happen very often and if we switch out the TIVA part and the "bad" board now works, that will give us confidence it was an issue with the particular TIVA part (which we would catch during our board testing).  I'll let you know what the result of that test is next week.

    Thanks,

    Mitch

  • HI Mitch,

      Yes, please keep us posted. We will go from there. 

  • Hi Charles,

    I wanted to let you know that we got a board back from our manufacturer today where they had just replaced the TM4C129 on the board, and the board now works fine and is able to wake from hibernation and execute code.  So we are going to chalk this up to a part issue with the TM4C129.

    Would you agree with that assessment?

    Thanks,

    Mitch

  • Hi Mitch,

      Thanks for the update. Did you also have a chance to swap the bad board MCU to a known good board? If the MCU was bad, then it should still be bad after it is soldered to a good board. I just wanted to make sure that it wasn't any bad soldering problem in those 4 bad boards. After replacing the 4 boards with the new units, the new soldering just happened to fix and mask the problem. These type of problem can occur.  Can you also do this swap and test?

      Another note to you is that we don't handle RMA in the forum. Once you fully confirm it's a MCU problem, you will need to either talk to the distributor where you purchased the devices from or talk to your local TI sales office. Please understand my limitation in terms of RMA support. Thank you.

  • Thanks Charles,

    We did not swap the bad part to a good board yet, and unless we see this issue happen on more than the couple of devices we have already seen, we are not going to spend more time debugging this issue.  And no problem with the RMA, if we feel we need these devices RMA'd we will go through proper channels.

    Mitch