STM32U5 Standby Mode and IWDG issue

[jcjunker]

Hello, I am seeing an issue with an STM32U5 battery powered system in the field. I use IWDG to reset the device in the occurrence of a software issue, and put the device into standby mode to sleep for periods of time before being woken up by either RTC or a wakeup pin. I was seeing cases where the devices weren't going to sleep after calling HAL_PWR_EnterSTANDBYMode, and they would proceed to drop into a while loop, and eventually reset with the IWDG. To attempt to rectify that, I attempted to continuously try to put the device into standby mode with the following code:

while (1)
    {
        for (int i = WWDG_IRQn; i <= DCACHE2_IRQn; i++)
        {
            NVIC_ClearPendingIRQ(i);
        }

        __HAL_PWR_CLEAR_FLAG(PWR_WAKEUP_FLAG1);

        HAL_PWR_EnterSTANDBYMode();
    }

My thought was that one of the interrupts or a race condition with the wakeup pin was occurring while trying to enter standby mode, preventing it from doing so. Unfortunately, I'm now seeing devices constantly stuck in this while loop, not going into standby mode, and the IWDG is no longer triggering. Is there any reason why this could be happening? I've read through the TRM, datasheet, erratas, etc. and haven't been able to find an answer. My theories are as follows:

1. Does clearing the IWDG interrupt somehow refresh the IWDG?

2. Does attempting to enter standby mode too quickly cause it to fail for some reason?

3. Are there other things preventing standby mode from being entered? Interrupts, power conditions, clocks, etc.

Any help or insight would be greatly appreciated.

[KnarfB]

Not directly for U5, but here are Piranha's recommendations: How to enter Standby or Shutdown mode on STM32 - STMicroelectronics Community

I don't get the point where you start the IWDG and what it is supposed to do during standby. Same with RTC wakeup timer. Guess the RTC wakeup is (much) longer than IWDG timeout. Maybe you could post more relevant code / option bytes.

Why not using __disable_irq() instead of NVIC_ClearPendingIRQ individually? Is NVIC_ClearPendingIRQ safe when an irq re-appears?

hth

KnarfB

[jcjunker]

Thanks for the response. The IWDG is disabled in standby, and isn't used to wake up the device. The RTC is used to wakeup the device periodically, i.e. to post data using a modem to a server every hour or so, depending on the situation. The IWDG is used exclusively to reset the device if it gets stuck in code somewhere, which is what it should do in the while loop I posted above. It works fine if it's an empty while loop, but seems to not trigger when the interrupts are cleared, and the request to enter standby mode is made, and it fails to actually enter standby. My understanding in the case of clearing each interrupt individually is that if any enabled interrupts that would wake the device from standby are pending, then the device will not enter standby. It doesn't seem that it prevents it from entering standby if any interrupts are pending, but I'm attempting to clear them all just to be sure. In reference to the linked post, this is all essentially what I'm doing as you can see above, but I'm using the HAL library function to set the device into standby. 

[KnarfB]

> but I'm attempting to clear them all just to be sure

When a peripheral has an interrupt condition, say USART TXE (transfer register empty), NVIC_ClearPendingIRQ is useless, because the interrupt condition still holds, and the interrupt pending bit will be set by the peripheral again immediately. So the important thing is that all interrupt handling is disabled.

hth

KnarfB

[jcjunker]

I'll try adding that in. But, my understanding is that regardless, the device should still be able to enter standby mode as long as any of the enabled interrupts that are able to wake the device in standby mode aren't pending, which I've checked as well as I can with logging and debugging where possible. Disabling the interrupts shouldn't really have any effect on entering standby mode, since standby mode is dependent on the actual peripheral interrupt flags and not the NVIC pending flags.