Update S32K144 watchdog twice

[DarrenD]

I am using

• "S32 Design Studio for ARM" version 2.2 (build ID 200116)
• S32K144EVB-Q100 dev board with chip labelled FS32K144UAVLL 0N57U QAR1751AU
• Connected to the PC via PE Micro Multilink Universal FX (part# USB-ML-UNIVERSAL-FX)

Using the S32DS debugger environment I can step through my code and notice that the watchdog is initialised to 0x2980 (matches the reference manual's reset value). I can change its settings to 0x73A0 (which then reads back as 0x37A0) with the code below. I have already set #define DISABLE_WDOG 0 so that system_S32K144.c does not permanently disable the watchdog.

/* reload_value is either 0xFFFF or 0x1234 passwed as a uint32 parameter */
DISABLE_INTERRUPTS();
WDOG->CNT = FEATURE_WDOG_UNLOCK_VALUE;       /* Unlock watchdog configuration */
while ((WDOG->CS & WDOG_CS_ULK_MASK)  == 0)
{
    /* Wait until the watchdog is unlocked */
    __asm__ volatile("nop");
}
WDOG->TOVAL = reload_value;
WDOG->CS = (WDOG_CS_WIN(0))     | /* Disable window mode */
           (WDOG_CS_FLG(1))     | /* Clear any previous interrupt */
           (WDOG_CS_CMD32EN(1)) | /* Enable 32 Byte command words */
           (WDOG_CS_PRES(1))    | /* Enable the 256 pre-scaler */
           (WDOG_CS_CLK(3))     | /* Clock source is SIRC */
           (WDOG_CS_EN(1))      | /* Enable the Watchdog counter */
           (WDOG_CS_INT(0))     | /* No watchdog interrupt - reset straightaway */
           (WDOG_CS_UPDATE(1))  | /* Enables the Watchdog reconfiguration */
           (WDOG_CS_TST(0))     | /* Disable Watchdog test mode */
           (WDOG_CS_DBG(0))     | /* Disabled in chip debug mode */
           (WDOG_CS_WAIT(0))    | /* Disabled in chip wait mode */
           (WDOG_CS_STOP(0));     /* Disabled in chip stop mode */
while ((WDOG->CS & WDOG_CS_RCS_MASK) == 0)
{
    /* Wait until new configuration takes effect */
    __asm__ volatile("nop");
}
ENABLE_INTERRUPTS();

If I call the same function again (with a different "reload_value") it gets stuck using the debugger waiting for the unlock. I need to change the timeout parameter "reload_value" several times in our software so it is not possible to just setup the watchdog once only.

I was originally using "Optimise most (-O3)" but had the same effect using "None (-O0)" as I had seen other posts that suggested optimisation had an effect.

If I step through with the debugger I can see it looping on the second watchdog function call waiting for the unlock to occur. Interestingly if I just run the code then it works and I can run to lines outside of this function and show that the WDOG->TOVAL is set correctly. However, I want to get the same effect when running and also debugging. I looked at WDOG->CS bits WDOG_CS_DBG, WDOG_CS_WAIT and WDOG_CS_STOP in the reference manual but it does not explain in detail what these bits actually do and when I would want to set them to 0 or 1. I have tried the following combinations of the DBG/WAIT/STOP bits

• 0/0/0 (runs fine "stepping over" this function both times, but hangs single-stepping on second call's unlock loop)
• 1/0/0/ (crashes after "stepping over" this function the first time)
• 0/1/0/ (runs fine "stepping over" this function both times, but hangs single-stepping on second call's unlock loop
• 0/0/1 (runs fine "stepping over" this function both times, but hangs single-stepping on second call's unlock loop)
• 1/1/1 (crashes after "stepping over" this function the first time)
• 0/1/1 (runs fine "stepping over" this function both times, but hangs single-stepping on second call's unlock loop)

I am expecting them to allow an enabled watchdog but not trigger a watchdog reset when the code breaks at a breakpoint (since a user can't kick the watchdog with the CPU stopped) and also to not hang waiting for the watchdog to unlock.

Is there something that I am obviously doing wrong? Is it these 3 bits in WDOG->CS?

Thanks

Darren

[DarrenD]

Thanks Daniel for the description of DBG=1.

What would be the sensible use case for DBG=1? I could guess as a security measure to stop others snooping around my code, i.e. they would not be able to hit a breakpoint my code because as soon as they do they would need to kick the watchdog every 50ms or so which would be impossible in a debugger session. So for my code development and testing I will definitely need DBG=0.

I am still not sure "wait mode" (WAIT) and "stop mode" (STOP) are, but I would guess that setting these to 0 is probably what most people use. Can you confirm that please?

I think that puts me back to the point where my code can configure the watchdog multiple times (a necessity) by running or stepping over the functions but I cannot single-step in the watchdog update function. I do not understand the reason for this behaviour. Is it that even though I am single-stepping the code by pressing F5, after stepping over the unlock code I still only have 128 bus clocks (real-world time) to complete the update and loop on the configuration pin (CS.RCS)being set? However, since I am single-stepping with F5 it takes about a second (real-world time) between F5 keypresses and this is longer than the 128 bus clocks? I had hoped that the CPU knows it is being halted by an emulator and so the 128 bus clocks only get counted when the CPU is actually running the instructions, i.e. after each F5 keypress and not whilst being halted. This is why I then started looking at the DBG/WAIT/STOP bits. Can you please confirm this is correct and, hopefully, suggest some setting that lets me single-step the code. I realise that this might not be the full story since I could single-step the first call that updates the watchdog but not the second. I am clearly missing some key information here.

Even if I don't get the answers to my questions above I can progress my software development knowing that I can't single-step the watchdog functions but am able to run over them. That is a big improvement in where I was last week.

Thanks

Darren

[danielmartynek · Accepted solution]

Hi Darren,

Regarding the DBG bit, it is not about security but safety.

You can refer to the S32K1xx Safety manual (rev 7.1) that is available on the SafeAssure NDA community.

Section 5.6.2.1 Debug mode

https://community.nxp.com/groups/safeassure-nda

https://community.nxp.com/docs/DOC-335524

Basically, if for any reason the MCU gets into the debug mode, it won't stay there for long because of the WDOG.

The WAIT function is not implemented on this device, but STOP is.

if STOP = 1, the WDOG is active in low-power mode of the MCU.

The WDOG is independent of the core.

The debugger halts the core but not the whole system (system clock).

I'm afraid it is not possible to step through the reconfiguration like that.

Please note that WDOG is unlocked by default until it is reconfigured from the default configuration.

You don't need to use the Unlock sequence in the first function - that is the reason why it works there.

Regards,

Daniel

[danielmartynek]

Hi Daren,

• If DBG = 1, the WDOG is active in the debug mode, it will reset the MCU while the core is halted and the WDOG is not refreshed.
• The WDOG stays unlock only for 128 bus clock cycles, so once unlocked, it should not be interrupted until the reconfiguration is done.

BR, Daniel