我正在为STM32F407VG写一个低功耗应用。它进入待机模式，可以通过两种方式唤醒：
取决于应用程序是被RTC还是按钮唤醒，我需要执行两个不同的任务。因此，当固件从待机模式唤醒后复位时，我必须找出唤醒原因（RTC或按钮）。
我已经进行了必要的配置，可以从任一来源从待机模式唤醒，并且它们都在工作-处理器确实会定期唤醒，或者在我按下按钮时唤醒。问题在于找出唤醒原因。
RTC_ISR寄存器的WUTF的文档说明如下：
Bit 10 WUTF：唤醒计时器标志
此标志由硬件设置，当唤醒自动重载计数器达到0。
此标志由软件通过写入0清除。
此标志必须在WUTF被清除之前至少1.5个RTCCLK周期被软件清除。再次设置为1。
这对我来说似乎很完美，如果设置了此标志，那一定是因为唤醒计时器达到0并唤醒了处理器。
我在固件的开头插入了一些代码以读取WUTF并根据它设置一个LED，然后在那之后立即清除该标志。不幸的是，不仅由于RTC从待机模式唤醒时，而且由于按钮唤醒，甚至是首次接通电路时，都始终设置此标志。
我检查了此MCU的勘误表，但未提及此问题。
我确实意识到解决方法是读取按钮的状态，如果它对应于按下状态，则假定唤醒原因是由于按钮被按下。但是，在回到待机模式之前，我的固件在运行模式下仅运行了几微秒，并且由于按钮的弹跳问题，除非我将运行模式的时间延长到几微秒，否则这种检测是不可靠的。反过来，这会影响我的应用程序的平均功耗（进而影响电池寿命）。虽然添加电容器可能会有所帮助，但我想尽可能实现仅软件的解决方案。
完全是我的坏事。我正在通过以下HAL宏读取标志：
__HAL_RTC_WAKEUPTIMER_GET_FLAG(&hRTC, RTC_FLAG_WUTF);
事实证明，我在初始化hRTC.Instance之前就在使用它，因此它不是读取RTC的寄存器，而是读取一些随机存储器（可能是地址0）。修复后，该标志似乎可以正常工作。