2398030_en-US

[#1]

S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays

Hello,

I am working with S9KEAZN16AM and would like some clarification regarding WDOG initialization timing.

Configuration

• MCU: S9KEAZN16AM
• Bus Clock: 16.777216 MHz
• WDOG Clock Source: 1 kHz LPOCLK
• Reset Type: Software Reset (SYSRESETREQ)

According to the KEA64 Reference Manual, after the watchdog unlock sequence:

"On completing the unlock sequence, the user must reconfigure the watchdog within 128 bus clocks; otherwise, the watchdog forces a reset to the MCU."

ppande19_1-1784788705383.pngppande19_1-1784788705383.png

With a bus clock of 16.777216 MHz:

128 bus clocks ≈ 7.63 µs

Observations

Our current implementation requires the following delays for reliable operation:

Software_Reset();

SysTick_DelayUs(2500);

DisableInterrupts();

WDOG_Init(&Wdog_cfg);

SysTick_DelayUs(80);

EnableInterrupts();

We observe two issues:

1. If the 2.5 ms delay after Software_Reset() is removed or reduced, the watchdog counter does not always start/run correctly.

2. If the 80 µs delay after WDOG_Init() is removed, the watchdog configuration is not always applied correctly.

Questions

1. Is the 128 bus clock requirement only the configuration window after unlock, or does additional internal synchronization occur afterwards?
2. Can the use of the 1 kHz LPO clock introduce additional synchronization delays?
3. Is there any known startup timing requirement after a software reset that could explain the need for ~2.5 ms?
4. Is there a recommended status bit or polling mechanism that should be used instead of fixed delays?

The main point of confusion is that the observed delays (80 µs and 2.5 ms) are significantly larger than the timing implied by the documented 128 bus clock (~7.6 µs) requirement.

Any guidance would be greatly appreciated.

Thank you.

Re: S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays

you try to initialize the watchdog or run tight timing loops before the ICS has completely locked, your actual bus clock frequency will be lower or unstable during that window. A lower actual bus clock means that 128 bus cycles will take significantly longer than 7.6 µs, or your initialization sequence executes before the hardware peripherals are fully out of their reset state. The ~2.5 ms delay gives the ICS ample time to achieve a full lock and stabilize the 16.777216 MHz bus frequency.  

Re: S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays

Hello,

Wait ~2.5 ms for the Internal Clock Source (ICS) to achieve a full lockand stabilize the bus clock (16.777216 MHz). Initializing the watchdogor running tight loops too early results in an unstable/lower clock,causing timing discrepancies or executing before peripherals leave reset.