WATCHDOG TIMER NOT RUNNING ON MKE04Z128VLH4

[robertogiovinet]

Hello everybody

I spent a lot of time to try to get watchdog running, but I can't obtain any results.

I configured Watchdog as below:

At the begininng a routine called __init_hardware() in the c file arm_strart.c sets the WDOG as

void __init_hardware()
{
   SCB_VTOR = (uint32_t)__vector_table; /* Set the interrupt vector table position */

   /* Disable the Watchdog because it may reset the core before entering main(). */

   WDOG_TOVALH = 0x00; // setting timeout value
   WDOG_TOVALH = 0x64; // setting timeout value
   WDOG_CS2 = 0x01; // setting 1-kHz clock source
   WDOG_CS1 = 0x27; // Watchdog disabled,
   // Watchdog interrupts are disabled. Watchdog resets are not delayed,
   // Updates allowed. Software can modify the watchdog configuration registers within 128 bus clocks after performing the    unlock write sequence,
   // Watchdog test mode disabled,
   // Watchdog enabled in chip debug mode,
   // Watchdog enabled in chip wait mode,
   // Watchdog enabled in chip stop mode.
}

In the main of the program I immediatly call MCU_Init() procedure, and I reconfigure WDog registers as below:

void MCU_Init(){

      //-------------------------- WATCHDOG -------------------------------------------------------------------
      DisableInterrupts;
      
      WDOG_CNT = 0x20C5; // write the 1st unlock word
      WDOG_CNT = 0x28D9; // write the 2nd unlock word
      WDOG_TOVALH = 0x00; // setting timeout value
      WDOG_TOVALL = 0x6E; // setting timeout value 0x6E = 110ms...
      WDOG_CS2 = 0x01; // setting 1-kHz clock source
      WDOG_CS1 = 0x87; // enable counter running
      EnableInterrupts;

      ....

When I control WDOG register during Debug session I can see that the values above are written in the registers, but the counter doesn't run, and so I don't have the MCU reset after 110ms. I can't understand why! I've tried to run software not in the Debug mode, but the result is still the same. I've checked examples and I think that I'm not doing mistakes, Ican't really understand why it doesn't work!

Thank you very much!

Roberto

[mjbcswitzerland]

Hi

This is how to set up the KE04's watchdog for a 2s timeout:

UNLOCK_WDOG();
WDOG_CS2 = (WDOG_CS2_CLK_1kHz | WDOG_CS2_FLG);
WDOG_TOVAL = BIG_SHORT_WORD(2000); // 2000ms timeout
WDOG_WIN = 0;
WDOG_CS1 = (WDOG_CS1_EN);

where
#define BIG_SHORT_WORD(x) (unsigned short)((x << 8) | (x >> 8))
and UNLOCK_WDOG() is
WDOG_UNLOCK = 0x20c5;
WDOG_UNLOCK = 0x28d9;

Beware that the WDOG_TOVAL is in fact in big-endien representation of the value which often catches new users out so you may find that you are  programming a timeout of 28.16s with your code rather than the 110ms that you are expecting....

Regards

Mark

Kinetis for professionals: http://http://www.utasker.com/kinetis.html

[robertogiovinet]

Hi Mark

Thank you very much for your suggestions.

I've tried your solution (similar to the one in the datasheet of the MCU) but it still doesn't work. I can see values in the registers that are ok, but the counter doesn't start and so I can't see the MCU reset. I don't know why!! I left my application run for several minutes before to ask to community, to understand if the time of the refresh was very long, but nothing, the application still run correctly.

Roberto

[mjbcswitzerland]

Roberto

I have never had probems with the watchdog on any KE or KEA parts apart form first tests where it may have been identified that the short work access is importantant also the fact that the example in the user's manual is wrong...

Ths is reported and discussed also in other threads:

https://community.nxp.com/message/498593?commentID=498593#comment-498593 

https://community.nxp.com/message/501132?commentID=501132#comment-501132 

Beware also that if the initial code disabled the watchdog but doesn't set the CS1[UPDATE] to a 1 it means that it is not possible to modify it again - it will always remain disabled whatever you do...

Regards

Mark

Kinetis for professionals: http://http://www.utasker.com/kinetis.html

[robertogiovinet]

Hello Mark,

I tried in these days to manage WDOG, but I didn't do any goal: nothing changed.

You told me about CS1[UPDATE] bit but I knew it, so it was one of the first things I've checked. As you can see in the imagine below, registers are well setting! Values that I expected are in the registers, but counter don't start and so I don't have any reset. I disabled in __init_hardware() the part of the WDOG, so here you can see the only WDOG implementation in the code. 

I read discussions in the links you gave me, but I didn't find anything that could be useful. I don't understand what's the matter, if there's anything else to set or maybe  a particular register that I didn't set correctly. I don't know... I always used WDOG in my projects in the past and I didn't experienced this troubles.

Thank you very much

Roberto

[mjbcswitzerland]

Hi Roberto

If you have a binary code that will run on any of the KE boards here:
http://www.utasker.com/kinetis.html
you could post it so that I load it to monitor the issue and see whether I can identify why it is happening.

Regards

Mark
Kinetis for professionals: http://www.utasker.com/kinetis.html

[wolframbraeuer]

Hello Mark,

I am using KDS 3.2.0 with MKE04Z128 and I had the same problem with Watchdog.

Thanks to BIG_SHORT_WORD it is working now correctly!

But I do not understand why it is only used with WDOG_TOVAL and not with WDOG_CNT (it is also a 2x8=16Bit register)?

WDOG_CNT = 0x20C5;      //1st unlock word
WDOG_CNT = 0x28D9;      //2nd unlock word
WDOG_TOVAL = BIG_SHORT_WORD(80);   //80ms wd timeout

Regards

Wolfram

[davidsherman]

The unlock sequence works on WDOG_CNT by virtue of those are the appropriate values to do a 16-bit write.  If you actually looked at what was going into WDOG_CNTH and WDOG_CNTL during the unlock, they would be reversed from what you might expect (WDOG_CNTH would be 0xC5, WDOG_CNTL would be 0x20 for the first value).   I suspect the unlock sequence only works if you do 16-bit writes. I got bit by WDOG_TOVAL following the examples given in the KE06 manual, not noticing the note showing that the endianness of the ARM may cause it to be swapped.