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.

TM4C123GH6PM: Hibrnation problem

Part Number: TM4C123GH6PM


Hi all, I am having problem with hibernation module. I am using my custom board and compiler is IAR. I want to enable hibernation module and wake by using external wake pin. When I debug I see code is stuck at while(!(HWREG(HIB_CTL) & HIB_CTL_WRC)) in HibernateWriteComplete(void) function. I think that means it never complates write operation. The code is below. Thanks in advance.

Edit: I have cr1220 3.3v battery connected to Vbat pin of mcu. Also 32khz crystal is connected to mcu as connected in launch pad

void AppHibernateEnter(void)
{
  SysCtlPeripheralEnable(SYSCTL_PERIPH_HIBERNATE);
//  HibernateEnableExpClk(SysCtlClockGet());

  while(!SysCtlPeripheralReady(SYSCTL_PERIPH_HIBERNATE))
  {
  }
  
  //HibernateGPIORetentionEnable();
  
  
  HibernateClockConfig(HIBERNATE_OSC_LOWDRIVE); 
  
  SysCtlDelay(SysCtlClockGet() / (1000 * 3));
  
  HibernateWakeSet(HIBERNATE_WAKE_PIN);
  
  HibernateIntEnable(HIBERNATE_INT_PIN_WAKE);
  
  HibernateIntClear(HIBERNATE_INT_PIN_WAKE | HIBERNATE_INT_LOW_BAT | HIBERNATE_INT_RTC_MATCH_0);
  
  HibernateRequest();
  
  SysCtlDelay(100);
  
  UARTprintf("The controller did not enter hibernate.\n");

  //
  // Wait here.
  //
  while(1)
  {
    
    UARTprintf("IN HIBERNATE WHILE\n");
    SysCtlDelay(10000000);
  }
  
}


void HibernateIntHandler(void){
  
      
  uint32_t ui32Status;
  //
  // Get the interrupt status and clear any pending interrupts.
  //
  ui32Status = HibernateIntStatus(1);
  HibernateIntClear(ui32Status);
    
    
  UARTprintf("IN HIBERNATE INTERRUPT\n");
}

  • I've no experience w/this vendor's "Hibernation Module" (their past LM3S series were power "hogs") yet should not you question the, "Ability to Debug" while w/in "Hibernation?"      (if indeed - that's the state you reach - that detail has (yet) to be provided.)

    Have you tried to:   (separate from Debug - following gleaned while the MCU is running - then ordered to "hibernate.")

    • put the MCU into hibernation
    • left it there for a few minutes
    • then provided the proper signal upon the "wake" pin

    That's a (reasonable) summary of the hibernation (entry - remain - exit) process - is it not?     The results would prove of value.

    We note that you employ the UART ... after ... you place the MCU into hibernation!      Can that be legal?      Aren't most of the MCU peripherals "shut-down" to reduce power consumption - during hibernate?

    This systematic approach - and your clear reporting of specific results - appears a valid diagnostic method...

  • You are right uart shouldn't work while mcu is in hibernation, but the thing is if mcu goes in hibernation at HibernateRequest(); line, the program counter doesn't go next lines, so uart won't be a problem. If mcu doesn't go in hibernation, I am able to understand by using uart. But main problem is, in debug mode I can see that program stucks wherever it goes to HibernateWriteComplete(void) function in hibernate.c library. Almost all hibernate functions have HibernateWriteComplete(); command. So I am unable to use any of hibernate function in hibernate.c

  • Based upon your response (thank you for that) would it not prove wise for you to:

    • Using the, "Peripheral Driver User Guide" (or whatever its "Nom du jour" is today) carefully examine function, "HibernateWriteComplete(void)" with the goal of "your" discovery of  "Why the Fault ISR" is entered.     If that function is "complex" - it may make "calls" to other functions - and each of those must be "recognized" (and findable) by your program.
    • If "HibernateWriteComplete(void)" is complex (calls multiple other functions) simply "comment it out" - and replace it with (one at a time) the functions which it calls.     (it must be that one - or several (God forbid even ALL) of the functions it calls - which lands you w/in the "dreaded" Fault ISR!)       (Fault-ISR is "home" too often for, "KISS Non-Believers!")
    • Should the test above identify "Faulting functions" - you must insure that each is defined & declared - and (really) is located where your code "thinks" it is.
    • One way to avoid this "extra effort" is to closely (i.e. exactly) follow the vendor's closest  Code Example!       Get that basic code to work - before you attempt ANY modifications.

    Rather than using the UART to confirm that you are, "Within Hibernation" - would it not prove more effective to create a simple, "Blink Led loop" (which you've done in the past) which confirms the MCU is "Alive/Awake" (when blinking) and which signals, "Entry into - and remaining within - Hibernate" when the blinking ceases?     For simplicity - I'd like that blink loop to be the only code running (besides the necessary config of the MCU for Hibernation.)

    "KISS" was (past) recommended to you - it seems that you've not (yet) "seen the bright light KISS casts" - and are deviating from the KISS RULE of, "One simple objective - at a time!"    (i.e. the systematic, single-step approach - as listed here...)

    Note that the question asked (earlier) re: Wake pin - remains unanswered...     Yet your first goal should be to, "Enter Hibernate" - later on we'll worry about "Exit."     That's KISS - and KISS WORKS!

  • I don't use the hibernation either, although I'd check the documentation on how it's supposed to behave because your report doesn't convince that it isn't working properly.

    Furkan ERMAN said:
    Almost all hibernate functions have HibernateWriteComplete(); command.

    Which leads to the obvious question, which function is it in. I could well believe this happens at the end of HibernateWriteComplete and is a symptom of success.

    One other note, at least on some micros it is not possible to debug the hibernate sequence since either using debug wakes up the micro or the micro is not operating and therefore cannot be successfully queried.

    Robert

    Also check if there are TIVAWare examples of hibernate.

  • Robert Adsett72 said:
    I could well believe this happens at the end of HibernateWriteComplete and is a symptom of success.

    Vendor (or predecessor) wins no awards for so obtuse a name.       Yet - although bit camouflaged - poster has noted that his call of that function leads directly to, "Fault ISR."

    That noted - your phrase, "is a symptom of success" is sure to have literary agents (once again) "speed-dialing into idyllic Ontario..." 

    We have both noted: "re-read, re-check MCU Manual; likely is not possible to debug when w/in hibernation; search out & employ/use as model - as much as possible - vendor examples.

    (and I believe there was (some) slight "call for KISS...")

  • cb1_mobile said:
    Yet - although bit camouflaged - poster has noted that his call of that function leads directly to, "Fault ISR."

    Are you sure? It looks like a status check loop not a fault ISR loop to me.

    Robert

  • Ok - the use of "Fault ISR" was more "inventive" than factual - yet was (somewhat) "hedged" via "bit camouflaged." (although that camouflage may have been noted (only) by moi...)
  • Thanks for your reply, you are right it is not about Fault ISR. I checked the manual and it says HIB pin should be high when mcu is in hibernation. So maybe debugging and uart can't be suitable method to track mcu. I will try to see by using to measure HIB pin. By the way, I couldn't find example for tm4c123, but found example for tm4c129. 

  • May the record show that a, "Blink or Not Blink Led method" was suggested as a "foolproof" method of recognizing "Hibernation Active."

  • I have tried everything I can, but couldn't make it work. I used the code given in the link below. I took only the essential parts for hibernation and used for tm4c123, but hib pin was low for all the time. Is there a way to use rtc without using hibernation? 

    github.com/.../hibernate.c