Hal Rtc alarm Interurpt firing at startup possible bug report on stm32wl55

[Mric.1]

Dear community,

I recently faced a possible anomaly in Stm32 cube configuration when setting up the RTC alarm:

the rtc alarm interrupt was firing immediatley during initialization.

• Everything was setup via Cube, no manual code involved.
• Problem begins immediately when in void HAL_RTC_MspInit(RTC_HandleTypeDef* hrtc) the RTC IRQ is enabled, after that it start to fire non-stop, at this point no alarm has been configured yet.

This because in the HAL_RTC_AlarmIRQHandler(&hrtc) the alarm interrupt flag is cleared only if hrtc->IsEnabled.RtcFeatures is evaluated true, since the configuration hasn't been carried out yet, the interrupt flag is not cleared and the program gets stuck.

My supposition is that the interrupt fires because of the RTC alarm registers content at reset, I haven't investigated but it seems the only logical reason.

My solution is to ignore hrtc->IsEnabled.RtcFeatures when clearing the alarm interrupt flags.

BEFORE

void HAL_RTC_AlarmIRQHandler(RTC_HandleTypeDef *hrtc)
{
 uint32_t tmp = READ_REG(RTC->MISR) & READ_REG(hrtc->IsEnabled.RtcFeatures);
 
 if ((tmp& RTC_MISR_ALRAMF) != 0U)
 {
 /* Clear the AlarmA interrupt pending bit */
 WRITE_REG(RTC->SCR, RTC_SCR_CALRAF);
 
#if (USE_HAL_RTC_REGISTER_CALLBACKS == 1)
 /* Call Compare Match registered Callback */
 hrtc->AlarmAEventCallback(hrtc);
#else
 HAL_RTC_AlarmAEventCallback(hrtc);
#endif
 }
 
 if (( tmp & RTC_MISR_ALRBMF) != 0U)
 {
 /* Clear the AlarmB interrupt pending bit */
 WRITE_REG(RTC->SCR, RTC_SCR_CALRBF);
 
#if (USE_HAL_RTC_REGISTER_CALLBACKS == 1)
 /* Call Compare Match registered Callback */
 hrtc->AlarmBEventCallback(hrtc);
#else
 HAL_RTCEx_AlarmBEventCallback(hrtc);
#endif
 }
 
 /* Change RTC state */
 hrtc->State = HAL_RTC_STATE_READY;
}

AFTER

void HAL_RTC_AlarmIRQHandler(RTC_HandleTypeDef *hrtc)
{
 uint32_t tmp = READ_REG(RTC->MISR) & READ_REG(hrtc->IsEnabled.RtcFeatures);
 
 if ((tmp& RTC_MISR_ALRAMF) != 0U)
 {
 
 
#if (USE_HAL_RTC_REGISTER_CALLBACKS == 1)
 /* Call Compare Match registered Callback */
 hrtc->AlarmAEventCallback(hrtc);
#else
 HAL_RTC_AlarmAEventCallback(hrtc);
#endif
 }
/* Clear Flag*/
 if( READ_REG(RTC->MISR) & RTC_MISR_ALRAMF) != 0U ){
 /* Clear the AlarmA interrupt pending bit */
 WRITE_REG(RTC->SCR, RTC_SCR_CALRAF);
 }
 
 
 
 if (( tmp & RTC_MISR_ALRBMF) != 0U)
 {
 
#if (USE_HAL_RTC_REGISTER_CALLBACKS == 1)
 /* Call Compare Match registered Callback */
 hrtc->AlarmBEventCallback(hrtc);
#else
 HAL_RTCEx_AlarmBEventCallback(hrtc);
#endif
 }
 /* Clear flag */
 if (( READ_REG(RTC->MISR) & RTC_MISR_ALRBMF) != 0U)
 {
 /* Clear the AlarmB interrupt pending bit */
 WRITE_REG(RTC->SCR, RTC_SCR_CALRBF);
 
 }
 /* Change RTC state */
 hrtc->State = HAL_RTC_STATE_READY;
}

[Jon3]

Hi,

I am experiencing the same thing. My code was auto generated by CUBE MX using firmware package FW_G0_V1.4.1. Upon execution of this line: HAL_NVIC_EnableIRQ(RTC_TAMP_IRQn), interrupts keep coming and cannot be stopped or cleared. This stalls the entire system as the processor can't perform any task other than servicing the interrupt. I tried a similar solution to yours but it doesn't really work. My STM chip is STM32G071.

Any ideas? I can't seem to get around this.

Thanks in advance!

[AELGH1]

Having the same issue on stm32wle5. @Mric.1​ any luck yet ?​

[KImlay]

Dear Mric.1 and others facing this same issue,

I have been facing this same issue, where the RTC Alarm A is firing immediately upon initialization in the HAL_RTC_MspInit() function.  I can only speak for my own configuration/application, but maybe what I have figured out can help us all find the root cause.

I am using the STM32WL55JC2 development board (STM32WL55 MCU) and developing in the M4 core, though the M0+ core is enabled. The RTC is enabled and Alarm A is enabled with the NVIC for interrupts.

Using just the Cube32MX generated code my MCU falls into an infinite loop of the Alarm A IRQ being called in the NVIC.  Like Mric.1 pointed out, HAL_RTC_AlarmIRQHandler() never clears the ALRAMF bit in the RTC_MISR like it should since hrtc->IsEnabled.RtcFeatures never evaluates to true at this point in the code.  It will only evaluate to true once the code for setting and enabling the alarm executes, which is after the initialization.

hrtc->IsEnabled.RtcFeatures is used as a flag to signal which core is supposed to handle the interrupt from the RTC.  The RTC fires an interrupt in both the M4 and the M0+ cores on my platform, so the code has to decide which core is supposed to handle it.  So ignoring this condition when clearing the alarm interrupt flag isn't actually fixing the problem, but may actually break something elsewhere if you're using a multi-core system.

It appears that when the APB clock is enabled to the RTC in the function __HAL_RCC_RTCAPB_CLK_ENABLE(), in the HAL_RTC_MspInit() function, this is when the alarm fired bit is set (ALRAMF bit in the RTC_MISR register).  Since the MCU is preoccupied by the Alarm A interrupt that can never get cleared, the MCU can never get to the code that enables the condition to clear it.

Possibly the RCC is misconfigured in my application, or this is a scenario the developers of the Cube32MX never anticipated.  If I find a workaround that doesn't require altering HAL code, or if I find what is going on with the RCC I will post again.  Hopefully this can lead you guys to a solution too.

Sincerely,
KImlay

[CKlem.1]

I have the same issue on stm32wle5, is there any solution existing ?