• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 389 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:

RTC will sometimes miss waking from hibernate

TM4C129ENCPDT: Intermittent waking up from hibernation mode when using "TM4C129ENCPDT"

George Gendy1
Prodigy 145 points
Part Number: TM4C129ENCPDT

Hello,

The issue I am currently facing is with theTM4C129ENCPDT. It sometimes stuck in hibernation mode.

My application is using TIRTOS (and using CCS V9.1). The application execution is continuously cycling between hibernation and wake mode (through RTC).  It is in wake mode for couple of seconds then goes to hibernation for couple of minutes. When I uploaded the application into some boards (lets say 6 independent boards), all works as expected for around 2-3 days. After that, I see some of them getting stuck in hibernation mode in different point times, sometime day(s) apart, while others just continue to work fine, although all of them have the same HW and FW.  I looked in this forum and found out that a similar issue was reported but with the "LX4F120H5QRF".

I implemented that fix and it does not help.

Please advise.

Thanks

  • 0
    TI__Guru*** 135355 points

    Hello George,

    The first thing that comes to mind for me is the errata for HIBCTL that is documented at HIB#19: https://www.ti.com/lit/pdf/spmz850

    Can you see if that may potentially be impacting your system?

    Can you post the code used for the hibernation configuration?

    Also are you sure the board is stuck in hibernation mode, i.e. is the current consumption indicating it is? Just a curious thought but maybe depending when it goes to sleep, something with the RTOS is not being recovered properly could be another explanation? Just trying to come up with ideas as I haven't come across an issue like this before. Usually the problem is getting into hibernate mode, not missing as wake up.

  • 0 in reply to Ralph Jacobi
    Prodigy 145 points

    Hi Ralph,

    Thanks for the fast response and feedback. I 'll connect the system to a power supply that has a current indication to make it easy to notice the change in the current.  I have not looked at the HIBCTL issue yet. 

    I can send you the project privately. Please email me and I will attach it to my reply. Thanks!

  • 0 in reply to George Gendy1
    TI__Guru*** 135355 points

    Hello George,

    I sent you an E2E friend request, with that we can start a private message to transfer the project files.

  • 0 in reply to George Gendy1
    TI__Guru*** 135355 points

    Hello George,

    Sorry for the delay here, had to talk with another team as well about what we could gather regarding the issue. Unfortunately, I don't have the best news to deliver in regards to helping you with a solution for this.

    Essentially hibernate mode has not been tested with TI-RTOS at any point as there wasn't really any requests to use the hibernate mode with RTOS. The hibernation mode basically works a shutdown mechanism as stated the datasheet:

    When the Hibernation module wakes, the microcontroller performs a normal power-on reset. The normal power-on reset does not reset the Hibernation module or Tamper module, but does reset the rest of the microcontroller.

    So with that said, the concern here from an RTOS standpoint is that when the call is made, something with the OS state may not be in a position to handle a re-boot properly and that is what is causing the hang-up.

    Furthermore, with so many calls to Hibernate throughout your software, it is hard to say what is actually triggering the issue.

    Debugging that will be challenging but a couple ideas:

    1) Have a JTAG probe connected so when a board hangs, you can connect to the core and try and get info on the current state.

    2) Add some method to output what state the MCU is in before hibernating and see if it is always resetting in the same function.

    3) Maybe add code into the Fault ISR handler so if that is what is triggering, you can see that it is a System Fault that is occurring. Could give us a big hint if so.

  • 0 in reply to Ralph Jacobi
    Prodigy 145 points

    Hi Ralph

    I attached the debugger to 2 units that were hanging last week (sent you the screenshots). Weird enough, once I started stepping though the code from that point on, the execution went forward as if the unit was not hanging. Hope these could give you a clue?

    Thanks,

    George

  • 0 in reply to George Gendy1
    TI__Guru*** 135355 points

    Hi George,

    I had seen your private message on Thursday but I was waiting for some additional feedback from the RTOS team regarding your findings.

    Seeing the API you are in being Hwi_getStackInfo is interesting and it makes me wonder if there is a check going on for stack overflow maybe? You could step through to the return and see if the return value is a '1'. If so, then that would indicate a stack overflow.

    Another thing to check when connecting the debugger is to see if you can load the ROV to check on the kernel state, task stacks, etc. to see if maybe that could offer some indicator.

    It is strange to me that the debugger connection is triggering things to move on. But if you are sure the devices are not stuck in hibernation mode, then I am not sure why that is the case.

    Ultimately for debugging this, you may need to remove different features or hibernation calls and see where the problem lays. The downside of that method is given the amount of time it takes for an issue to occur, it could take a lot of time to track down. However, I would anticipate that you could shorten your hibernation time to make the device go in and out of hibernation mode more often and shorten the test time. I don't think it will matter if it sleeps for 2 seconds or 60 seconds. I think this will present based on how many times or what state the device is in when it goes into hibernation. That would hopefully let you do tests in a span of hours instead of days.