Infinite Wait for Watchdog Reconfiguration Success (RCS) Bit

[stephandewit1]

I have noticed on my S32K148 MCU that the watchdog timer is not being consistently configured when I am running through the debugger.  I have never seen this problem when running without the debugger.  The code in question is below.  This is the first code executed during device startup.  I want to disable the watchdog before initializing various peripherals.  Then when reaching the main loop the watchdog is then enabled.

/**
* Disable the watchdog timer.
*/
void watchdog_Disable(void)
{
   DISABLE_INTERRUPTS();

   // The Unlock write is only required when CS_ULK == 0
   // Out of reset CS_ULK == 1 making the Unlock write not necessary
   if (((WDOG->CS & WDOG_CS_ULK_MASK) >> WDOG_CS_ULK_SHIFT) == 0U)
   {
      // Unlock watchdog
      WDOG->CNT = 0xD928C520;
      // wait until unlocked, CS_ULK == 1
      while (((WDOG->CS & WDOG_CS_ULK_MASK) >> WDOG_CS_ULK_SHIFT) == 0U);
   }

   // Maximum timeout value
   WDOG->TOVAL = 0x0000FFFF;

   // Disable watchdog
   // CMD32EN = 1 : Enables support for 32-bit refresh/unlock command write words.
   // CLK = 1 : LPO clock
   // EN = 0 : Watchdog disabled.
   // UPDATE = 1 : Updates allowed. Software can modify the watchdog configuration registers within 128 bus    clocks after performing the unlock write sequence.
   WDOG->CS = WDOG_CS_CMD32EN(1) | WDOG_CS_CLK(1) | WDOG_CS_EN(0) | WDOG_CS_UPDATE(1);

   // wait until new configuration takes effect, CS_RCS == 1

   while (((WDOG->CS & WDOG_CS_RCS_MASK) >> WDOG_CS_RCS_SHIFT) == 0U);

   ENABLE_INTERRUPTS();
}

The device hangs on while (((WDOG->CS & WDOG_CS_RCS_MASK) >> WDOG_CS_RCS_SHIFT) == 0U);  near the bottom of the function. It appears that the RCS bit never gets set and this seems to happen because the device is still locked.  However the check above should ensure that the device is unlocked before trying to write to the watchdog control and status (CS) register. Below is a capture of the watchdog registers when the device hangs.

S32DS debugger when device hangs.

This does not happen consistently and I cannot reproduce this problem on demand.  When this problem does occur power cycling the MCU and starting a fresh debug session clears the problem.

• Is there something wrong with my watchdog disable function? 
• Am I running into a timing problem or race condition with the watchdog?
• Is there a known issue configuring the watchdog while debugging? 

Any thoughts help is appreciated.

[danielmartynek]

Hello Stephan,

I'm unable to reproduce this behavior with your code. 

Could you send a test project?

Nevertheless, the default S32K1xx startup code in S32 Design Studio disables the WDOG.

SystemInit() funtion, system_S32K148.c.

This code is enough to disable the WDOG and allow subsequent updates in main().

Regards,

Daniel

[stephandewit1]

I now see that my watchdog disable function is unnecessary if DISABLE_WDOG is defined, that is good to know.  This also explains why the watchdog control and status (CS) register did not have its reset value loaded when I was setting the register, it had already been changed earlier in the SystemInit() function.

To be clear this problem, my code hanging waiting for the watchdog CS register RCS bit to be set after reconfiguring the watchdog, is intermittent.  I do not know the steps to reproduce on demand.

I still wonder if its somehow related to interactions between the Design Studio IDE and the PE Micro Multilink debugger.  When I arrived this morning and plugged in the debugger and started a debug session I found that the device hanged in the same spot as mentioned above.  It looks like the watchdog will not unlock after it is disabled in SystemInit() code.  Any attempt to unlock or reconfigure and wait for the associated bit to indicate success will hang.  When in this state I can reprogram the S32K148 with new code and get the same result.  Only a power cycle will get the device out of this state.

Do you have any suggestions on what information I could gather with the IDE when/if I can get the device watchdog in this state again?  I will try to put together a stripped down test project that exhibits the same behaviour and send it your way.

[stephandewit1]

The problems I was having configuring the watchdog are related to its clock source being disabled in a different part of the code.  This LPO disable is not cleared by a reset.

To save power consumption when sleeping the Low Power Oscillator (LPO) is disabled just before sleeping (or Very Low Power Stop (VLPS)) and enabled during wake-up.  The watchdog is clocked by the LPO.  However there was an error in how the LPO was enabled leaving the it permanently disabled after the first sleep cycle.

As per the reference manual below the Power Management Controller (PMC) LPO disable (LPODIS) is *only* cleared on a power on reset (see note 1. below).  This left the watchdog disabled between resets, even resets from the debugger.  This explains why power on resets were the only way to resolve the problem.

From Reference Manual Power Management Controller (PMC)

Another take away from this self made bug is that enabling the watchdog and waiting for its Reconfiguration Success (RCS) bit will not work when the watchdog clock has been disabled.  Makes sense but was not obvious at first.