Posted on May 07, 2018 at 22:03The priority of the interrupt plays no role AFAIK: it wakes up the CPU, sent asleep by WFI instruction. I have not ever tested or created the situation when one tries to issue WFI while any high priority interrupt is disabled but pending. Analyze your NVIC state by debugger just before the WFI instruction. Don't forget to force stopping any running timers when debugging: see DBGMCU unit, and avoid any communication processes that could trigger an interrupt (UART, I2C, etc...) when you stay at WFI.
Try to check if the RTC interrupt is really enabled at all, both in the RTC peripheral registers and in NVIC, and the RTC is really running (any crystal issues?).
By the way. You say, you deinit UART before getting asleep. First, it's not neccessary at all because UART consumes no power when its clock is stopped (STOP mode); second, as soon as the UART is deactivated, its assigned TX pin goes in some undefined output level about VCC/2 what can lead to the significant current consumption at a CMOS input attached to this pin. The state of the UART is preserved during the STOP mode; the only reason, why you obtained the garbage characters from the UART after waking up, is that the whole RCC must be reinitialized after the STOP mode; it's done by the call to SystemInit(). That all is my proved experience form the last month .
