Unexpected Behavior with RTC ALARM_A in LowPoer Mode on STM32WB55

[JR2963]

Hello everyone,

I’m working with an STM32WB55 microcontroller with BLE stack. I use also low-power modes in my app. Before entering a low-power mode, I set an RTC ALARM_A to wake the system up at a specific time. The device then enters either Sleep or STOP2 mode with the RTC enabled.

However, I’m noticing an issue where, when in these low-power modes, the RTC ALARM_A does not seem to wake the device as expected. The timing appears to freeze or behave unpredictably, and the alarm sometimes triggers late or not at all.

Here is the output just before entering sleep mode with the configured alarm:

Current time vs Alarm RTC Settings:

(PREDIV_S = maximal SubSec = 32000)

| Field | Current (Cur) | Alarm (Alm) |
|------------|------------|--------|
| SubSec | 7234     |  6594|
| Sec       | 21          | 21      |
| Min       | 0            | 0        |
| Hr         | 0            | 0        |
| Day      | 1            | 1        |
| Mon     | 1             | 1        |
| Yr        | 0             | 0        |

 When I pause the execution, I see that the program is halted right after the WFI() instruction. I also see that the current time is much further ahead (by the duration I was stuck), the seconds were already at 25. 

All the relevant registers appear to be configured correctly for the RTC ALARM_A interrupt:

• The RTC_CR register has the ALRAIE bit (Alarm A interrupt enable) set to 1, so the RTC ALARM_A interrupt is enabled.
• The EXTI_IMR register has bit 17 set to 1, which means the interrupt for the RTC ALARM is unmasked (enabled).
• The EXTI_RTSR bit 17 set to 1
• The interrupt for RTC ALARM is enabled in the NVIC.

Has anyone else encountered similar issues with RTC alarms in these low-power modes? Could there be any configuration or known issue that might cause this behavior?

Any insights or suggestions would be greatly appreciated!

[STTwo-32]

Hello @JR2963 

I think that one of the RTC errata on the ES0394 can be the reason behind that (specially the number 2.12.1).

Best Regards.

STTwo-32

[JR2963]

 @STTwo-32  @waclawek.jan  @Piranha I studied ES0394, and I think this is not my problem. The situation described there warns about shared EXTI lines. However, I have only activated ALARM_A, and even then, the hazard would occur very rarely. In my case, however, it happens in the vast majority of the set alarms.

From the data I wrote, it's clear that ALARM A should have already occurred, but no IRQ was triggered. It's as if the alarm wasn't activated. When stopped in debug, ALRAF is not set either!

[STTwo-32]

Hello @JR2963 

Are you facing the same issue will the BLE stack is not activated?

Best Regards.

STTwo-32

[JR2963]

I tried disabling all initialization related to the BLE stack and radio, and the behavior is the same.

[STTwo-32]

Could you share a firmware that reproduce the issue (with and without BLE stack if possible).

Best Regards.

STTwo-32

[JR2963]

Well, I'm not sure how to approach this; it's quite a complex firmware with a built-in custom tickless mode. I'll try to trim it down as much as possible.

[JR2963]

@STTwo-32  That won't work. I've created a clean project (WITHOUT BLE) where I enter sleep mode using HAL_PWR_EnterSLEEPMode(PWR_MAINREGULATOR_ON, PWR_SLEEPENTRY_WFI);. Now, it behaves such that, although the sleep should last one second, the MCU wakes up immediately. I don't know the source of the wake-up, but it's not the RTC, so I'm facing a different problem here. In this project, there is only a FreeRTOS timer that blinks an LED every second, nothing more - nothing what should wakes up the MCU

BTW: By the way, is there some sort of protection against sleep in this MCU? Why does it immediately wake up from sleep? What is causing it to wake up?

[JR2963]

Hi, Please are you going to provide any solution or advice from your side? I'm really stuck and don't know what to do next. Thank you.

[JR2963]

Hi, Finally, I managed to create an empty project where I only enter STOP and SLEEP modes (without the BLE stack) and wake up using the RTC ALARM_A. In this project, everything seems to work as expected. The RTC always wakes up the MCU at the correct time. I suspect that the problem in the application with the BLE stack is caused either by the BLE stack itself or by some other peripheral (there are quite a few, like SPI, TIMERS, ADC, DMA, UART). However, it is difficult to pinpoint exactly where the problem lies.