STM32U575 Watchdog Mechanism

[RLanz.2]

Hi 
We want to use STM32U575 Watchdog Mechanism in our operational FW, but have the following concerns:

1. Can MCU ST Bootloader kick the WD in general, and especially duringca FW update, when it is busy writing/reading to flash the new FW to update or during its execution prior to jumping to the FW?

2. How can we maintain debug capabilities - no resets during debugging - is there a debug settings taking care of it?

3. How can we log events of resets which happened due to WD - can the RCC be examined during startup to analyze if the reset was due to a watchdog?

4. How can we log events of resets which happened due to WD - can an early IWDG interrupt be used and how? Would I have enough time to log info to some non-volatile memory (e.g. EEPROM)?

5. When is best to initialize and activate the watchdog during the FW startup - especially when we have some long wait (seconds) during the FW startup to overcome some initialization problem we currently face?

6. Can the watchdog setting be changed or disabled AFTER it was already activated?

7. What are the main considerations to choose to work in Software or hardware watchdog mode?

Thanks in advance for any relevant info.

[TDK]

1. The ST bootloader does not interact with the watchdog. If it's enabled when you jump to the bootloader, the watchdog will eventually reset the device.

2. You can halt the watchdog during debugging. Look at DBG_IWDG_STOP in DBGMCU registers.

3. Yes, see IWDGRSTF in RCC_CSR register.

4. Yes, there is an early watchdog interrupt that should give you enough time to write to EEPROM.

5. It's up to you, but generally, when your program is done initialization and starts running user code. Errors before that point are generally fatal (i.e. won't be fixed by a reset) while errors in user code often will be.

6. You cannot disable it once started. Fairly sure you can change the duration.

7. Hardware watchdog is always enabled, so enabled immediately after reset. Software watchdog needs to be started. Again, up to you what you want to do. I would say generally the watchdog interrupt is more common.

The reference manual goes into detail on most of these topics.

https://www.st.com/resource/en/reference_manual/rm0456-stm32u5-series-armbased-32bit-mcus-stmicroelectronics.pdf

[RLanz.2]

Thanks for a detailed answer.

There are three items I want to further clarify

Item 1:
Q1. Can MCU ST Bootloader kick the WD in general, and especially during a FW update, when it is busy writing/reading to flash the new FW to update or during its execution prior to jumping to the FW?

A1. The ST bootloader does not interact with the watchdog. If it's enabled when you jump to the bootloader, the watchdog will eventually reset the device.
Q. My question now:

I look at https://www.st.com/resource/en/application_note/an2606-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf
Chapter 4.8 for IWDG usage in Bootloader,
Chapter 76 for IWDG & relevant STM32U575xx
And the info is not clear to me.

How in general can we perform a procedure of a SW update using the STM32U575xx Bootloader, if we enable the WD by the SW program (after it's done initialization and starts running user code), and then the SW program jumps to Bootloader (per a host request to start a SW update)? How can we make sure the WD will not reset during bootloader is busy in the SW update (it involves getting SW program fragments via FDCAN and writing them to the flash memory, and reading back from flash to verify write was ok)?


Item 2:
Q4. How can we log events of resets which happened due to WD - can an early IWDG interrupt be used and how? Would I have enough time to log info to some non-volatile memory (e.g. EEPROM)?
A4. Yes, there is an early watchdog interrupt that should give you enough time to write to EEPROM.
Q. My question now: can the early watchdog interrupt set to any time before the actually reset expected due the WD itself? Is there any difference in the WD mechanism of reset or any other aspect when using or not using the early interrupt option?


Item 3:

Q6. Can the watchdog setting be changed or disabled AFTER it was already activated?
A6. You cannot disable it once started. Fairly sure you can change the duration.

Q. My question now:
I look at https://www.st.com/resource/en/product_training/STM32WB-WDG_TIMERS-Independent-Watchdog-IWDG.pdf and it says one can set the WD to any period between from 125 microseconds to 32 seconds. So, can I freely change the duration of the WD once started in this time range?

Thanks for your support.

[TDK]

Don't enable the watchdog before you jump. Consider setting a flag in your program, resetting, and checking for that flag on startup, before you set watchdog, and jumping to the bootloader.

The other questions are covered in detail in the reference manual (and/or my previous post).

[RLanz.2]

Thanks for a prompt answer.

I'm not sure I've understood your suggestion. 

After its initialization is done, our FW requires that the WD would be activated, during its execution, to catch malfunctioning.

It can receive a request in CAN from the host to perform a FW update during its execution, thus it needs to jump to ST bootloader for the FW update procedure.

How do you suggest we can achieve both functionalities - the WD to protect during our FW execution, and the need of FW update using the ST bootloader?

Thank you

[TDK]

> How do you suggest we can achieve both functionalities - the WD to protect during our FW execution, and the need of FW update using the ST bootloader?

By this:

Consider setting a flag in your program, resetting, and checking for that flag on startup, before you set watchdog, and jumping to the bootloader.

I can step through this in a little more detail:

• In your program, define a global uint32_t flag = 0; in a section of memory that isn't initialized (NOLOAD in linker script, or by placing it at an exact address which isn't otherwise touched).
• At program startup, if flag = 0x12345678, jump to the bootloader. Do this check before enabling watchdog.
• Enable watchdog.
• During your program, when you want to jump to the bootloader, set flag = 0x12345678 and reset the chip. This will cause the flag check to pass and the firmware will jump to the bootloader with the watchdog disabled.

[RLanz.2]

Thanks for elaborating.

Ok, that seems like an optional solution, though it will add have complexity impact on the FW update procedure, and the flag will need to mark both the need for not activating the WD and the need for a FW update:

• Build the FW program with a flag set to activate WD in an uninitialized section of memory.
• Any FW startup will read that flag and activate the WD.
• Once the host will send a FW update request, the running FW will need to write the flag a special value for not activating the WD and perform a FW update on next startup.
• Then the running FW will need to reset the MCU.
• On startup read that flag value and reset it back to allow WD for next startup.
• Jump to bootloader in order to perform the FW update itself. 
• At the end the host will ask bootloader to jump to (new) FW execution.
• Newly updated FW will start, read that flag and activate the WD and so on.

[TDK]

If the check comes before activating the watchdog (which it should), you don't need to worry about that complexity. Just adding more things that can go wrong by having another flag.