STM32H725 IWDG fails to initialize

[blockworker]

Hi everyone,

I'm developing a bare-metal application with an STM32H725RG MCU using STM32CubeIDE (including HAL and code generation).

I want to use the IWDG1 for reliability purposes, but for some reason, it seems to not work for me at all - upon startup, the MCU enters the Error_Handler loop, due to the HAL_IWDG_Init call returning HAL_TIMEOUT.

In particular, I enabled the IWDG1 in the .ioc file editor, so it gets initialized and enabled by the generated HAL code. This enables the LSI as expected (RCC_CSR = 0x3), and I can confirm that the LSI itself works by outputting it to the RCC_MCO_2 pin.
However, the initialization of the IWDG doesn't seem to complete. As far as I can tell from debugging, all the initial writes to IWDG_KR work as expected, and IWDG_PR and IWDG_RLR receive their correct values. This results in IWDG_SR = 0x3 as expected, which should go back to 0x0 within a few LSI cycles as the changes are applied - but this never happens. Instead, IWDG_SR remains at 0x3 permanently, causing the initialization to time out and the MCU to get stuck.

There doesn't seem to be any mention of such behaviour in the datasheet, RM, or device errata - does anyone have any ideas about what could be going on?

Thanks,

Alex K

[Sarra.S]

Hello @blockworker, 

SR=0x03 meaning the watchdog reload and prescaler value are still updating, have you taken into consideration that this update can take up to 5 RC 40Hz cycles causing the timeout! 

Rechecking with you the IWDG initialization, can you confirm you're following this sequence: 

• Enable the IWDG by writing 0x0000 CCCC in IWDG_KR
• Enable register access by writing 0x0000 5555 in IWDG_KR.
• Write the prescaler by programming the IWDG_PR from 0 to 7.
• Write the IWDG reload register (IWDG_RLR).
• Wait for the registers to be updated: IWDG_SR = 0x0000 0000
• Refresh the counter value with IWDG_RLR (IWDG_KR = 0x0000 AAAA)

[blockworker]

Hi @Sarra.S,

Thanks, yeah I understand that much. The HAL code I'm using (generated by STM32CubeIDE) follows the above procedure and takes this expected time (5 cycles) into account.

The problem is that in my case, IWDG_SR = 0x0 never happens, as far as I can observe - no matter how long I wait, even if I wait several seconds. It constantly stays at 0x3. So of course this init procedure will time out or get stuck.

[Sarra.S]

Ok, that's quite odd, can you share your code so i can try and reproduce the behavior on my end? 

Meanwhile, for the sake of checking every possible root cause with you, if there is an issue with the VDD voltage domain, the update operations might not complete! 

Another thing is, if a write operation to the IWDG register is ongoing , maybe the value read is not up to date! 

Could you check these two hypotheses? 

[blockworker]

Sure, here is the IWDG initialization code, as generated by the IDE:

/**
 * @brief Initialize the IWDG according to the specified parameters in the
 * IWDG_InitTypeDef and start watchdog. Before exiting function,
 * watchdog is refreshed in order to have correct time base.
 * @PAram hiwdg pointer to a IWDG_HandleTypeDef structure that contains
 * the configuration information for the specified IWDG module.
 * @retval HAL status
 */
HAL_StatusTypeDef HAL_IWDG_Init(IWDG_HandleTypeDef *hiwdg)
{
 uint32_t tickstart;

 /* Check the IWDG handle allocation */
 if (hiwdg == NULL)
 {
 return HAL_ERROR;
 }

 /* Check the parameters */
 assert_param(IS_IWDG_ALL_INSTANCE(hiwdg->Instance));
 assert_param(IS_IWDG_PRESCALER(hiwdg->Init.Prescaler));
 assert_param(IS_IWDG_RELOAD(hiwdg->Init.Reload));
 assert_param(IS_IWDG_WINDOW(hiwdg->Init.Window));

 /* Enable IWDG. LSI is turned on automatically */
 __HAL_IWDG_START(hiwdg);

 /* Enable write access to IWDG_PR, IWDG_RLR and IWDG_WINR registers by writing
 0x5555 in KR */
 IWDG_ENABLE_WRITE_ACCESS(hiwdg);

 /* Write to IWDG registers the Prescaler & Reload values to work with */
 hiwdg->Instance->PR = hiwdg->Init.Prescaler;
 hiwdg->Instance->RLR = hiwdg->Init.Reload;

 /* Check pending flag, if previous update not done, return timeout */
 tickstart = HAL_GetTick();

 /* Wait for register to be updated */
 while ((hiwdg->Instance->SR & IWDG_KERNEL_UPDATE_FLAGS) != 0x00u)
 {
 if ((HAL_GetTick() - tickstart) > HAL_IWDG_DEFAULT_TIMEOUT)
 {
 if ((hiwdg->Instance->SR & IWDG_KERNEL_UPDATE_FLAGS) != 0x00u)
 {
 return HAL_TIMEOUT;
 }
 }
 }

 /* If window parameter is different than current value, modify window
 register */
 if (hiwdg->Instance->WINR != hiwdg->Init.Window)
 {
 /* Write to IWDG WINR the IWDG_Window value to compare with. In any case,
 even if window feature is disabled, Watchdog will be reloaded by writing
 windows register */
 hiwdg->Instance->WINR = hiwdg->Init.Window;
 }
 else
 {
 /* Reload IWDG counter with value defined in the reload register */
 __HAL_IWDG_RELOAD_COUNTER(hiwdg);
 }

 /* Return function status */
 return HAL_OK;
}

The timeout happens in the loop in lines 40-49. The HAL_IWDG_DEFAULT_TIMEOUT constant defaults to the maximum LSI startup time plus 6 cycles:

#define HAL_IWDG_DEFAULT_TIMEOUT (((6UL * 256UL * 1000UL) / LSI_VALUE) + ((LSI_STARTUP_TIME / 1000UL) + 1UL))

However, even if I increase the timeout to a large value (multiple thousand ticks, at 1 kHz tick rate), the behaviour stays the same - it still times out.

There shouldn't be any problems with the VDD voltage, as the MCU runs completely stable otherwise, at 520 MHz core frequency in VOS0.

At the point where the timeout happens, and after the timeout (in the error handler), there shouldn't be any more ongoing writes into IWDG registers - yet the debugger (expression watch) still reports IWDG_SR = 0x3 constantly, which is consistent with the fact that it times out.

[blockworker]

Hi @Sarra.S,

An update - in trying to reproduce the error, I have fully restarted my development workstation and the IDE and rebuilt the code again. Now the IWDG initialization seems to work fine (where before, it was failing consistently).

Maybe my build system was stuck in some kind of invalid state before the restart, producing a bad binary? Either that, or the error is intermittent in some other way.

Thanks for your help either way.

[mp1645]

For posterity I figured I would throw out my findings as I witnessed something similar (although maybe not the same but led me here). I had similar artifact where HAL_IWDG_Init() would spin waiting for SR register to update and never return, but since the watchdog was started the system would just boot loop. If I broke the code prior to reset I saw in the call stack that the system was hitting a hardfault and waiting there. The reason I came to find out was that the delay to init the IWDG was giving enough time for the SysTick_Handler() to trigger, and since I am using ThreadX that calls __tx_SysTickHandler(). Somewhere in this call chain ThreadX triggers PendSV interrupt (which calls __tx_PendSVHandler()) and attempts a context switch. Since I was initializing the watchdog prior to starting ThreadX, it faults because I hadnt actually set anything up yet for ThreadX. If I do the watchdog init after ThreadX is setup I have no issues. So perhaps yours was similarly timing related? Regardless hopefully this helps someone else out.

(gdb) bt
#0 HardFault_Handler () at /nix/store/j6dma7s3g1cbinxwagvwighfb2j4gcr8-nucleo-h723zg-1.0/src/Core/Src/stm32h7xx_it.c:89
#1 <signal handler called>
#2 __tx_PendSVHandler () at /nix/store/xnlkkdiwsnganyyii26cy51lv7q6v9gq-source/ports/cortex_m7/gnu/src/tx_thread_schedule.S:171
#3 <signal handler called>
#4 0x08024798 in HAL_IWDG_Init (hiwdg=0x24001358 <watchdog_data+4>)
 at /nix/store/j6dma7s3g1cbinxwagvwighfb2j4gcr8-nucleo-h723zg-1.0/src/Drivers/HAL_Driver/Src/stm32h7xx_hal_iwdg.c:205
#5 0x080212c0 in watchdog_init (config=0x80266bc <watchdog_config>) at /nix/store/1ck8yxrjbah87s29v4vbvwkfv5gzr7dq-watchdog-1.0/watchdog.c:75

 

[blockworker]

Thanks for your insight, it seems that I forgot to update this thread.

It started working as stated in my last post, but later broke again - it was really inconsistent.
Later, I realised that my MPU (memory protection unit) was misconfigured, potentially allowing writes to the IWDG registers to be consolidated or reordered by the CPU, when they really shouldn't be. My assumption is that this is what caused the inconsistent behaviour, though I can't be 100% sure if it was the cause.

Basically, make sure the peripheral registers are always configured as "Device" type memory, if any peripherals aren't behaving as expected.