WDOG Enabled at Reset

[sean_dvorscak]

I am looking into the WDOG peripheral and the KE1xF rev 4 reference manual says that the WDOG_CS[EN] bit is set to 1 at startup.  However I see the EN bit set to 0 at startup.

I am using IAR to debug, and I have not ruled out IAR not displaying the registers correctly.  I have also noticed that if my software does not configure the WDOG at all (use start up values) I see my software running perfectly with no issues (even though I am not refreshing the WDOG and it is supposedly enabled out of reset).  However, once I run the software without the debugger, it seems the system is just resetting and no longer outputting any data.  I assume because the WDOG keeps resetting it.  I also tried setting the WDOG_CS[DBG] bit, but that made the IAR debugger not run any more.  Anyone else have issues with IAR and the WODG?

What I am trying to do is witness what the register values of the WDOG are if you do not configure the watchdog properly in time.  The manual says to write to the CS and TOVAL registers to have a successful configuration, but what happens if I only write TOVAL.  Will TOVAL then reset back to 0x400 like the manual says the startup value is? 

[Robin_Shen]

Hi sean_dvorscak,

If you are test SDK example, then you will find the watchdog is disabled in SystemInit().

Best Regards,
Robin

[sean_dvorscak]

Yes I saw that.  And that is the code that I am editing and working with.

Some of the tests that I was trying to witness was commenting out that code that disables the wdog to try to get an idea of when the wdog starts counting.  Does it happen as soon as the LPO clock is received, or after the first 128 bus clocks that the reference manual mentions?

I also wanted to see what the register values would be if I didn't do a successful configuration of the wdog.  So I would write the CS register but not the TOVAL register, and I wanted to see if the CS register would set back to it's reset value, or just keep the register value, but run the startup configuration?

I was also surprised to see the WDOG_CS[EN] bit set to 0 before the SystemInit() function started.  I was viewing this in the memory window, and the registers window.  Not sure why it was 0 when the reference manual says that bit should be 1.

[Robin_Shen]

Sorry for the delay!
I don't know why the value of WDOG_CS[EN] will be 0 in IAR, since it was 1 in MCUXpresso IDE.

I am using TWR-KE18F, using CMSIS-DAP and JLink debugger get the same value 0 in IAR.

Best Regards,
Robin

[sean_dvorscak]

No worries about the delay.

I am not sure what is going on with IAR.  When I set the debugger up to not run to main, and step through the system_MKE18F16.c code, the values in the register file are not correct according to the reference manual.

These are the values I see before running any code in the system_MKE18F16.c file.  It seems as if the values that are inside the #if (DISABLE_WDOG) are somehow showing up in the register fields.

In the code that I am executing, I set the DISABLE_WDOG to 0, and give it my own configuration of this:

Not sure why I can't see the startup values that in the reference manual.

I did have a question about when the watchdog actually starts counting.  I was thinking about the WDOG->CS[TST] bits and was thinking that if you do a low byte test, and the WDOG starts counting once it is out of reset (the LPO clock is received), wouldn't the low byte test be initiated before you can configure the TOVAL register, and you would do a low byte test with a value of 0 putting you into an infinite reset?  That makes me think that the WDOG starts counting at some time after reset.  Does the watchdog start counting once you have a successful configuration (WDOG->CS[RCS] == 1), after the first 128 bus clocks, or just once the LPO clock signal is received (i.e. directly out of reset)?  

Does the WDOG->CNT register also set back to 0 on a successful configuration (WDOG->CS[RCS] == 1)?

[Robin_Shen]

WDOG counter is only reset to 0 (stays at 0 for one clock cycle) during the reconfiguration when the clock source is not changed.

When the clock source is changed during a reconfiguration:

The number of cycles it takes for the RCS flag to set should be:

[sean_dvorscak]

Thanks.  That helps a lot.

2 follow up questions:

1.)  If you wanted to use the default wdog configuration, so you didn't touch any of wdog registers, would the WDOG->CS[RCS] bit assert ever?  If so, when would that happen?

2.)  Does the wdog start counting only after the RCS bit asserts?

[Robin_Shen]

According to the description in the reference manual: RCS=0 by default.
The WDOG_CS[EN]=1 by default, it enables the watchdog counter to start counting.

[sean_dvorscak]

Yes, I see that.  That sounds like the WDOG starts counting right out of reset.  However two things don't seem to be right with that interpretation.

1.) If you were to do a low byte test by setting WDOG->CS[TST] = 0x2, and WDOG_TOVAL = 0xFFFF, the watchdog would then do a low byte test with the WDOG_TOVAL[TOVALLOW] = 0xFF.  When the watchdog finishes the low byte test, the WDOG will then reset.  However, the TST bits will still be set to 0x2, and WDOG_TOVAL would be reset back to 0x400 (according to the reference manual).  If the WDOG were to start counting right out of reset, and TST was still 0x2 and TOVAL was now 0x400, that would mean that the WDOG would do a low byte test with WDOG_TOVAL[TOVALLOW] = 0x00.  That would put you into an infinite reset scenario where you keep doing a low byte test with the low byte of 0.  So the WDOG has to start counting sometime after reset because I do not see this behavior when doing the low byte test.

2.) When I debug, I put in a while((WDOG->CNT & 0xFFFF) == 0) and compare to the CYCLECOUNTER in IAR.  The CYCLECOUNTER is typically in the 10's of thousands before WDOG_CNT > 0.  So that suggests the WDOG does not start counting after restart.

So when does the WDOG actually start operating, and does configuring the WDOG affect when it will start operating as opposed to just using the default configuration out of reset?

I am trying to build a simulator, and am trying to get the WDOG functionality figured out, and this is holding me up since I cannot for some reason witness the correct register fields in IAR.

[Robin_Shen]

Please follow the "30.4.7.1 Testing each byte of the counter"
After low byte should not be high byte?

[sean_dvorscak]

Yes you test the High Byte next, but aren't the TST bits not affected by the WDOG reset?  So when the WDOG starts up again after it reset from a low byte test, the TST bits would still be 0x2.

Or does the hardware automatically set the TST bits to 0x3 after a low byte test passed?