Having a problem with K61 Watchdog after software reset

[KenV]

I have recently discovered a problem that I can't seem to rectify regarding the K61 hardware watchdog.  I have enabled the watchdog when the firmware starts up and it seems to be working correctly.  However, I am trying to disable the watchdog prior to doing a software initiated reset, the board is somehow resetting where RCM_SRS0 is set to WDOG. 

If I disable the code that starts up the watchdog, then the RCM_SRS0 is set to 0 as expected.  The main problem I am having with the WD causing the reset is that I have DDR segments that are set to NOCLEAR, but when a WD reset occurs, the DDR is cleared, which is undesirable.  

How can I completely disable the watchdog so that it doesn't cause a reset reason of WD after doing a software reset?

Here is a brief snippet of the code that runs prior to the software initiated reset:

// Shutdown watchdog

__DI();
WDOG_UNLOCK = DEFAULT_FIRST_UNLOCK_CODE; //1st unlock code
WDOG_UNLOCK = DEFAULT_SECOND_UNLOCK_CODE; //2nd unlock code

//Disable watchdog
WDOG_STCTRLH &= ~(WDOG_STCTRLH_WDOGEN_MASK;

__EI();

// Perform reset

__DSB(); 
SCB->AIRCR = (uint32_t)((0x5FAUL << SCB_AIRCR_VECTKEY_Pos) |
(SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) |
SCB_AIRCR_SYSRESETREQ_Msk ); 
__DSB();

for(;;) /* wait until reset */
{
__NOP();
}

[KenV]

Update.  I think I figured out the circumstances that are causing my WD reset-reason issue, although I am not sure how to fix it.

It seems to be related to initiating a reset after power-cycling the board.  Here are the steps I followed:

1. Power-cycle the board.
2. Wait for the board and watchdog to enable.
3. Perform a software reset.
4. Check the RCM_SRS0 and it is now WDOG.

Note, that any reset that occurs after the first reset that followed the power-cycle will not report WDOG as the reset reason.  So, the problem appears to be related to performing the first SW reset after a POR.  

Now, the question still remains as to why this occurs and what can be done to fix it?

[jingpan]

Hi,

I made a demo to show the operation. It works fine, no WDOG bit set after reset.

This demo is base on the gpio example in KINETIS_120MHZ_SC package. When you click the PTE26 button, it will stop watchdog and reset.

Regards,

Jing

[KenV · Accepted solution]

I think I may have found and fixed the issue.  I was on the wrong trail with the POR.  Turns out the problem was because of a delay introduced in the code during reset operations.  The code was erasing and writing to flash memory just before the reset.  The watchdog was still enabled at this point, and because the watchdog thread was running at low priority, the thread was getting starved during the flash write, which was taking quite some time to complete.  I am not sure why this was brought out more with doing reset after POR, but I think that I have a pretty good handle on fixing this issue now. Basically going to either force a refresh of the watchdog before the flash update or disable it before the flash update.

Thanks for all the help!

[jingpan]

Hi KenV,

Please check the highlight part in below screenshot. You can add short delay to avoid.

Regards,

Jing

[KenV]

I've tried adding delays using a for loop after setting the unlock registers.  That doesn't seem to be helping the issue.  I've also tried adding a delay after setting WDOG_STCTRLL register.  Still no good.

The normal reset logic flows to completion, but when I read the RCM_SRS0 after the reset, it still has WDOG bit for the reset reason.