I am experiencing unexpected WDOG behavior according to my understanding of the reference manual in regard to the following:
"All watchdog control bits, timeout value, and window value are write-once after
reset within 128 bus clocks. This means that after a write has occurred they cannot
be changed unless a reset occurs."
My initial interpretation of this is that you must configure the WDOG within the first 128 bus clocks after reset, or it will use the default configuration with UPDATE=0. This will then prevent you from re-configuring the WDOG again.
I however am experiencing something different. Since the KE1 out of reset runs the Bus and Core clock at the same frequency, I decided to look at the CYCLECOUNTER in the IAR debugger when I reconfigure the WDOG, as I thought it would tell me how many bus clocks have also passed since reset. It showed 144 cycles had passed since release from reset. So I started adding longer and longer delay loops at the start of the function to see if it would still allow me to reconfigure well past 144 cycles.
No matter how long the delay, as long as it was below the default 8ms timeout of the WDOG, it would successfully reconfigure the WDOG. I observed this behavior with, and without the debugger, just to ensure the debugger did not play any role. I was also able to confirm timing via strobing the reset signal with Oscope.
So now my understanding of the reference manual is that you can reconfigure the WDOG once out of reset. And once you perform the first write to the WDOG, you get 128 bus clocks to reconfigure the remaining register fields.
For example, lets say I wait 1000 bus clocks out of reset and then configures the WDOG_CS register. I then get 128 bus clocks after configuring the WDOG_CS to configure the WDOG_TOVAL. Once TOVAL is configured, the new configuration takes effect.
Is this the correct interpretation of the reference manual? Or is my previous interpretation correct where you get 128 bus clocks out of reset, or the default configuration takes effect?