【发布时间】：2020-03-06 17:40:45
【问题描述】：
我正在为 STM32F407VG 编写一个低功耗应用程序。它进入待机模式，可以通过两种方式唤醒：
- 定期使用 RTC 唤醒定时器；
- 通过按下连接到 PA0-WKUP 引脚的按钮。
根据应用程序是由 RTC 还是按钮唤醒，我需要执行两个不同的任务。因此，当从待机模式唤醒后固件复位时，我必须找出唤醒原因（RTC 或按钮）。
我已经进行了必要的配置，以便从任一来源从待机模式唤醒，并且它们正在工作 - 处理器确实会定期唤醒，或者当我按下按钮时。问题在于找出唤醒原因。
RTC_ISR 寄存器的 WUTF 文档说明如下：
Bit 10 WUTF：唤醒定时器标志
当唤醒自动重载计数器时，该标志由硬件设置 达到 0。
该标志由软件通过写入 0 清除。
该标志必须在 WUTF 执行前至少 1.5 个 RTCCLK 周期由软件清除 再次设置为 1。
这对我来说似乎很完美——如果设置了标志，那一定是因为唤醒计时器达到 0 并唤醒了处理器。
我在固件的开头插入了一些代码来读取 WUTF 并根据它设置一个 LED，然后立即清除标志。不幸的是，这个标志总是被设置，不仅在由于 RTC 从待机模式唤醒时，而且在由于按钮唤醒时，甚至在第一次打开电路时也是如此。
我检查了这个 MCU 的勘误表，发现没有提到这个问题。
我确实意识到一种解决方法是读取按钮的状态，如果它对应于按下状态，则假设唤醒原因是由于按下了按钮。但是，我的固件在运行模式下仅运行几微秒，然后返回待机模式，并且由于按钮的弹跳问题，除非我将运行模式时间延长到几微秒，否则这种检测是不可靠的.这反过来会影响我的应用程序的平均功耗（以及电池寿命）。虽然添加电容器可能会有所帮助，但如果可能的话，我想实现一个纯软件解决方案。
【问题讨论】：
-
很抱歉我不了解这个平台，但这是一个有趣的问题。您的固件是否完全控制了平台，或者是否存在运行时可能会因为将唤醒视为比您想要的更多的重置而阻碍？
-
这是一个裸机平台。当我使用 FreeRTOS 时，它更像是一个库而不是底层平台。在查询标志之前，我不运行任何 FreeRTOS 代码。事实上，在查询之前运行的唯一代码是重置处理程序，我认为它不会对此负责。我将尝试在重置处理程序的开头添加一个断点，以确保在绝对运行任何代码之前检查标志。
-
阅读 STM 文档，似乎很清楚这应该可以按您的意愿工作，否则就没有任何意义。编程唤醒的频率是多少？
-
我使用 LSI 作为时钟源并要求每两秒唤醒一次。在实践中，由于 LSI 非常不准确，我测量的唤醒周期约为 3.5 秒。
标签： power-management stm32f4 standby