TM4C129XNCZAD: TIVA is hanging at HibernateEnableExpClk

Hi,

Erman Oezdemir said:

Both working and problematic boards have YM code as 82, so as i understand prod date is February 2018.

What do you mean both are working? Do these two boards work at one point of time but fail just recently? You said their production date is 2/2018. Can you confirm they were working since 2018 but just fail recently or they never work since they were produced.

Just to isolate the problem further, can you do a ABA swap test? Swap the MCU from the problem board to a good know board and can you still reproduce the problem? Swap a good known MCU into the problem board? Will the MCU continue to work?

 Looking at your schematic, I'm interested to know what is your mechanism of waking up the device. I see you connect WAKEn pin to the battery and power supply. Is that correct? Will WAKEn pin ever go low? WAKEn is a active low signal to wake up the device when the device is in hibernate mode. There are other methods to wake up the device such as to use I/Os to wake up the device from hibernate. Is that what your method is?

Hi Charles,

I am sorry that i could not convey my situation clearly to you. I am paraphrasing below

All of the 28 pieces of working PCBs and 2 pieces of problematic PCBs have YM code as 82, so as i understand prod. date is February 2018.

What i am talking about production date, is not the PCB production date. It is the TM4C129 production date. This information is based on the chip markings and the following document: https://www.ti.com/lit/er/spmz850g/spmz850g.pdf?ts=1654072704954&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTM4C1294NCPDT%253FkeyMatch%253DTM4C1294NCPDT%2BERRATA

They did not fail recently. The PCBs were produced a couple of days ago. The 2 problematic PCBs, which are giving this particular error, have never ever properly worked before.

WAKEn pin is not intended to go low. The device is not supposed to go to actually hibernate during the runtime. Whole idea of the using hibernate module is to use the real time clock and always have a correct date time through using HibernateCalendarGet function. (Of course after setting it in a first time use)

In the end, if there is nothing else i can do, i will eventually have to do an ABA swap test. Is there anything else I can do or try before i get unsolder the µc ? Or any workaround ? What is exactly causing the hanging of _HibernateWriteComplete function ? Any register that i can read to help identify the problem ?

Best regards,

Erman

Hi Erman,

  I find this errata that may be related to your observation. Can you try the workaround as mentioned?

Hi Charles,

With a breakpoint at the line of MAP_HibernateEnableExpClk, i read the WRC bit is already set.

WRC is the Bit31 in HIB_CTL register which is located in 0x400FC010 

The moment MAP_HibernateEnableExpClk is executed, WRC bit is set to 0.

Manually trying to overwrite the WRC bit or other bits in this register does not work.

To sum up, my problem is not solved.

Best regards,

Erman

Hi Erma,

  The WRC bit is a read-only bit. You cannot manually overwrite the bit. Can you please try the workaround as suggested in the errata which is to reset the hibernate module after the oscillator startup time has elapsed if the WRC bit does not change to a 1. After the hibernate module reset, perform a write again. The oscillator startup is about 600ms as stated in the datasheet. 

  I will suggest you first try something simple to see if it will make a difference. See below to first perform a software reset of the hibernate module before enabling it. 

void Board_InitHibernate(void)
{

SysCtlPeripheralReset(SYSCTL_PERIPH_HIBERNATE);
MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_HIBERNATE);
while (!MAP_SysCtlPeripheralReady(SYSCTL_PERIPH_HIBERNATE))
{
}

  snip...

If the above does not work then you will need to modify the driver function.

The code is hanging in the below function where it is waiting for the WRC bit to become 1. Check the source file at C:\ti\TivaWare_C_Series-2.2.0.295\driverlibhibernate.c. You can copy this file to your local project directory if you want to modify it without rebuilding the driverlib.lib. You will need to modify the code so the code will exit out of the while loop either after 600ms or after the WRC bit become 1. If the errata workaround still does not work then you may not have hit the errata but rather something else that I don't really know the cause. As you mentioned, you only see 2 out of 28 with unexpected behavior. The problem seems to be more hardware related. 

static void
_HibernateWriteComplete(void)
{
//
// Spin until the write complete bit is set.
//
while(!(HWREG(HIB_CTL) & HIB_CTL_WRC))
{
}
}

Perhaps you can also try to enable the peripheral and then reset like as follows. 

void Board_InitHibernate(void)
{

MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_HIBERNATE);
while (!MAP_SysCtlPeripheralReady(SYSCTL_PERIPH_HIBERNATE))
{
}

SysCtlPeripheralReset(SYSCTL_PERIPH_HIBERNATE);

while(!SysCtlPeripheralReady(SYSCTL_PERIPH_HIBERNATE))
{
}

  snip...

This did not help at all. Exactly the same situation as before.

WRC never becomes 1 after executing HibernateEnableExpClk(SYSTEM_CLOCK); line.

When i exit the loop, although WRC is not 1, it does not solve my situation, because afterwards HibernateCalendarGet function does not work.

Hi Erman,

  In my first reply to this post I suggested you to perform a ABA swap test. Please see my earlier reply again. Can you please provide feedback on this request?

"Just to isolate the problem further, can you do a ABA swap test? Swap the MCU from the problem board to a good know board and can you still reproduce the problem? Swap a good known MCU into the problem board? Will the MCU continue to work?"