Hibernation mode for TIVA C TM4C1299KCZAD.

Hello Vishal,

A couple of things to check on. First, can you query the hibernate status to see what the cause of the wakeup is? This will help in identifying the root cause. Also, I assume you are configuring the hibernate module with VDD3ON asserted, correct? If not using VDD3ON, the pin state will not be preserved.

Second, review of the schematic (off line) shows that there could be some issues with the circuit. First, nHIB should be connected directly to the EN of the buck converter without the need for a pullup to VBAT.

Finally, the circuit for the connection to EN looks a bit unusual to me given that there is a transistor with the mcu_nHIB input and output to the EN of the buck converter. Is this because the buck converter requires a higher voltage to actuate the EN? Still, this has a pullup to VSYS as well which could impact the EN pin state.

So, in summary,

1.) check on the WAKE source and let us know what this is

2.) Insure use of VDD3ON

3.) Try it with the pull ups in the nHIB circuit removed and a direct connection of nHIB pin to the EN pin of the buck converter if possible.

Hello Sai,

VBAT is stable and glitch free. Here is our Hibernation code attached.

/************************************************************************
**    FUNCTION NAME   : Hibernate_init
**
**    DESCRIPTION     : Initialize the hibernation module.
**
**    ARGUMENTS       : None
**
**    RETURN TYPE     : None
**
***************************************************************************/

void Hibernate_init(void)
{
	uint32_t ui32Status = 0;

    Types_FreqHz cpuFreq;

    //Get the CPU clock frequency(120MHz) set in BIOS
    BIOS_getCpuFreq(&cpuFreq);
	
    //Extract the 32-bit frequency value
    ui32SysClock = cpuFreq.lo;

    // Enable the hibernate module.
    SysCtlPeripheralEnable(SYSCTL_PERIPH_HIBERNATE);

    // Initialize these variables before they are used.
    ui32Status = 0;

    // Check if Hibernation module is already active, which could mean
    // that the processor is waking from a hibernation.
    if(HibernateIsActive())
    {
    	// Read the status bits to see what caused the wake.  Clear the wake
    	// source so that the device can be put into hibernation again.
    	ui32Status = HibernateIntStatus(0);
    	HibernateIntClear(ui32Status);

    	// System console prints to see which caused wakeup.
    	System_printf("Wake Due To : \n");

       	// Wake was due to the External Wake pin.
    	else if(ui32Status & HIBERNATE_INT_PIN_WAKE)
    	{
    		System_printf(" Wakeup Pin\n");
    	}
    }

    // Configure Hibernate module clock(120MHz).
    HibernateEnableExpClk(ui32SysClock);

    // If the wake was not due to the above sources, then it was a system reset.
    if(!(ui32Status & (HIBERNATE_INT_PIN_WAKE)))
    {
    	// Configure the module clock source.
    	HibernateClockConfig(HIBERNATE_OSC_LOWDRIVE);
		
    	// Print that this was a system restart, not wake from hibernation.
    	System_printf(" System restart\n");
    }
    // Enable processor interrupts.
    IntMasterEnable();
}

/************************************************************************
**    FUNCTION NAME   : HandleHibernate
**
**    DESCRIPTION     : Function to put device into Hibernate mode
**
**    ARGUMENTS       : None
**
**    RETURN TYPE     : None
**
***************************************************************************/

void HandleHibernate()
{
	uint32_t ui32Status = 0;
	
	// Read and clear any status bits that might have been set since last clearing them.
	ui32Status = HibernateIntStatus(0);
	HibernateIntClear(ui32Status);

	// Configure wakeup pin for Hibernate wakeup source.
	HibernateWakeSet(HIBERNATE_WAKE_PIN);

	// Request Hibernation.
	HibernateRequest();

	// Wait for a while for hibernate to activate.  It should never get past this point.
	SysCtlDelay(100);
}

Thanks,

Vishal

Hello Sai,

We configured clock in cfg script to system clock 120 MHz. Same is configured for hibernation module also as below:

// Configure Hibernate module clock(120MHz).
HibernateEnableExpClk(ui32SysClock);

// If the wake was not due to the above sources, then it was a system reset.
if(!(ui32Status & (HIBERNATE_INT_PIN_WAKE)))
{
// Configure the module clock source.
HibernateClockConfig(HIBERNATE_OSC_LOWDRIVE);

// Print that this was a system restart, not wake from hibernation.
System_printf(" System restart\n");
}

Regards,

Vishal Thakur

As I understand all these posts, we do not have obviously wrong implementation in our schematics or in our code. But the way our supplies fall when hibernation is ordered seem to cause the Tiva to either not finish the hibernation process or immediately wakeup.

Chuck, you recommended the implementation of delays, but we do not really understand either how and when to implement it, or how these are supposed to help.

Any additional inputs here would be welcome because we are somewhat dead in the water on this issue and not sure what to try next.

Hello Chuck, Sai,

Here are some more results we got today, we still do not have a solution, but hope these results will help getting there:

1/ RC network on VBat: we do have that implemented on our schematics: 50ohms in series between our 3.0V supply voltage and the Vbat pin, and 100nF connected between the VBat pin and ground. Id this network appropriate or other values should be tried?

2/ HIB vs power supply voltages:

HIB vs VBAT: Blue is HIB, Yellow – VBAT

HIB vs VDD: Blue is HIB, Yellow – VBAT

Another observation we got is that when our JTAG probe is connected to the board JTAG connector, the hibernation mode seem to work properly.
 We have not yet been able to get more details on this, but wanted to bring it up as it may help find new recommendations or things to try.

Looking forward to hearing from you soon.

Christophe

Hello Cristophe,

Thanks for the additional plots. One thing I notice is that the time that nHIB is asserted is slightly different in each of the two plots? How much variability do you see in the time that nHIB is asserted when putting the device into hibernate mode? Were you able to get any current readings on the VBAT supply when putting the device into hibernate? 

In regard to the RC circuit on VBAT, the values I see in the schematic provided offline match the TM4C129 design guidelines and should be fine. The question I had was more in line with is the RC populated as noted in the schematic or was something different used?

I'll have to think through the JTAG interaction a bit more to see if there might be some interacion contributing to this issue. Is the device in active debug mode when this works or is the probe simply connected and not active? Do you see any differences in the plots of VDD, VBAT, nHIB, when the probe is attached?