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