TM4C123GH6PM: tm4c123gh6pm Hibernate Mode to solve my problem:rest for a while and work for a while.

Hi Liguo,

  I don't see you configure the hibernate clock source by calling 

HibernateClockConfig(HIBERNATE_OSC_LOWDRIVE);

This may be the reason that your device is locked. The device tries to go into hibernate mode without the 32kHz crystal enabled. Since the RTC clock is not running without a crystal, there is never a RTC wakeup. The device is forever in hibernate. If you want to go into hibernate mode then you need to enable the external 32KHz crystal. See the below snippet of code presented in the Peripheral Driver Library user's guide.. You can also reference the similar example code in <TivaWare_Installation>/examples/boards/dk-tm4c123g/hibernate/hibernate.c

uint32_t ui32Status;
uint32_t pui32NVData[64];
//
// Need to enable the hibernation peripheral after wake/reset, before using
// it.
//
SysCtlPeripheralEnable(SYSCTL_PERIPH_HIBERNATE);
//
// Wait for the Hibernate module to be ready.
//
while(!SysCtlPeripheralReady(SYSCTL_PERIPH_HIBERNATE))
{
}
//
// Enable clocking to the Hibernation module.
//
HibernateEnableExpClk(SysCtlClockGet());
//
// User-implemented delay here to allow crystal to power up and stabilize.
//
//
// Configure the clock source for Hibernation module and enable the RTC
// feature.
//
HibernateClockConfig(HIBERNATE_OSC_LOWDRIVE);
HibernateRTCEnable();
//
// Set the RTC to 0 or an initial value. The RTC can be set once when the
// system is initialized after the cold startup and then left to run. Or
// it can be initialized before every hibernate.
//
HibernateRTCSet(0);
//
// Set the match 0 register for 30 seconds from now.
//
HibernateRTCMatchSet(0, HibernateRTCGet() + 30);
//
// Clear any pending status.
//
ui32Status = HibernateIntStatus(0);
HibernateIntClear(ui32Status);

//
// Save the program state information. The state information is stored in
// the pui32NVData[] array. It is not necessary to save the full 16 words
// of data, only as much as is actually needed by the program.
//
HibernateDataSet(pui32NVData, 16);
//
// Configure to wake on RTC match.
//
HibernateWakeSet(HIBERNATE_WAKE_RTC);
//
// Request hibernation. The following call may return because it takes a
// finite amount of time for power to be removed.
//
HibernateRequest();
//
// Need a loop here to wait for the power to be removed. Power is
// removed while executing in this loop.
//
for(;;)
{
}

Below steps are mentioned in the datasheet to enter the hibernate mode. 

Hi Liguo,

  The 16MHz is the "main" crystal connected to the OSC0, not the XOSC0. The main crystal can be the clock source for the entire device. It is also used as the source for the on-chip PLL for which you can select as a clock source running at higher frequency (i.e. 80MHz) The XOSC0 needs to be connected to either a 32kHz crystal or a 32kHz clock. On your launchpad there is the 32kHz crystal connected to the XOSC0 and therefore you need to enable the 32kHz oscillator. If you directly feed an external 32kHz oscillator clock into the XOSC (this may be the case if you have your custom board) then you can bypass or disable the 32kHz oscillator. 

 The device goes into hibernate mode after you call HibernateRequest(). I will suggest you read the datasheet for hibernate mode operation. Below is the excerpt from the datasheet.

The Hibernation module power source is determined dynamically. The supply voltage of the
Hibernation module is the larger of the main voltage source (VDD) or the battery/auxilliary voltage
source (VBAT). The Hibernation module also has an independent clock source to maintain a real-time
clock (RTC) when the system clock is powered down. Hibernate mode can be entered through one
of two ways:
¡ The user initiates hibernation by setting the HIBREQ bit in the Hibernation Control (HIBCTL)
register
¡ Power is arbitrarily removed from VDD while a valid VBAT is applied

All modules (i.e. Hibernate, SSI, UART, GIO and etc) have the same interrupt architecture. There is an raw interrupt (xxxRIS) and a masked interrupt (xxxMIS). When an interrupt event happens the raw interrupt flag is set. However, do you want to signal the CPU? If your application wants to signal the CPU with an interrupt event then you will need to enable it. To enable the interrupt so that it will signal the CPU you will need to set the xxxIM register. Think of a simple AND gate. The two inputs to the AND gate are the RIS and the IM and the output is the MIS. When you call HibernateIntStatus(false) you are checking the xxxRIS status flags. When you call HibernateIntStatus(true) you are checking the xxxMIS flags. 

  I think you need to read the Peripheral driver library user's guide and it is explained. 

Thank you so much,Charles,I will learn to read these dataSheets more.But sometimes I really can't understand what it means,hhh.

Hello Mr. Wang,

Vendor's Charles has given direct & detailed guidance - most excellent - we are glad to note that you have (properly) thanked him.

His advice regarding a, (perhaps) slower and repeat reading of the MCU Manual - also proves most sound.

Now w/in this past week - my young team provided advice to you - suggested was  your, 'Finding & Study/Reviewing w/others!'     This will enhance your grasp of English -  as well as your understanding and comfort level - w/these powerful - yet complex MCUs.   You may discover a team member who is 'best' at English - while you (quickly) become the MCU 'expert.'    Our young staff notes that you have (very) broad & wide ranging interests - which (likely) signals that you are NOT Following a standard college Engineering/Programming curriculum.    We don't believe that's optimal - as 'Scattered Learning' - most always - is 'Short-Term Learning' - as you've insufficient time allotted to Each MCU Peripheral...   The MCU manual is deliberately designed into 'Peripheral Sections' - which serves to 'Unify & focus Learning' - and has been proven to strengthen neurological connections.    Skipping often - from the discipline of, "One MCU Peripheral at a time' - may delay your understanding - and be 'too soon' clouded - even forgotten.

One last point - you have just 'Verified' your own post.   In reality - it was Vendor's Charles post - which (should have) been Verified.   As his post - properly guided - and enabled your issue resolution.    (The not too well known purpose (apparently) of the 'Verify' - is the speeded & eased direction of 'Future Thread Viewers' - to that post - which indeed 'Solved the Issue at hand!    I believe the choice of the word 'Verify' was mistaken - as it has a (near) double meaning:

• your post can confirm the correctness of another post (which actually resolved) your issue or problem.   Marking your post - which simply 'confirms the correctness of (another's) earlier posting - is a mistake.   (New posters - arriving at your thread - find 'No key content - w/in your Confirming Post - thus confusion reigns!)    
• the earlier post - which led to the resolution of your issue - is that post (alone) which should be 'Marked by the Green Verify.'
• my team believes that 'Verify' proves too vague - and should be replaced (sooner rather than later) w/'RESOLVING POST!'    That's a far stronger indicator of proper post marking - and even though 'NIH' - it deserves high consideration.

Posters - especially those 'outsiders' - who make regular & effort-heavy/detailed forum contributions - should have their successful efforts rewarded!   The present 'Verify' method is seriously flawed - and is quickly & easily corrected...