4

我在低功耗运行模式下从 RAM 运行 c 代码（因此不处理中断）。此模式由代码序列启用：

  • 跳转到内存
  • SIM卡
  • 关闭内部闪光灯和电源调节器，切换到低速时钟源 (LSE)
  • 使用 WFE 模式（低功耗等待模式）做一些工作
  • 打开电源调节器和闪光灯，恢复时钟源
  • 轮缘
  • 跳到闪光

因此，勘误表中描述的 WFE 指令没有问题。这种结构的问题，它可能是导致 CPU永远处于低功耗等待模式的原因：

while nbit(TIM1_SR1,CC3IF) asm("wfe");

即反汇编为：

000035    720252B602     BTJT      TIM1_SR1, #1, 0xB6
00003A    728F           WFE

来自定时器的事件具有概率性质，并且此代码不保证它会在 WFE 指令执行后发生：

  • BTJT指令在2个周期内执行，长度为5；
  • 从 RAM 执行的代码可能不连续，因为“获取”状态会在几个周期内暂停执行

我使用手册 PM0044，在第 26 页它包含漂亮的表格：

从 RAM 执行示例代码

代码执行停止在 3 个周期时有 2 种情况。所以我不确定我的异步唤醒事件不会在 BTJT 和 WFE 指令之间发生。

有没有办法确保严格的逻辑顺序（检查条件 > wfe > 唤醒事件）？

4

2 回答 2

5

如果您的锁定问题是由我提到的 WFE 勘误表引起的，那么应该有比尝试实现“正确的应用程序时间”更简单的解决方案。

意法半导体提供的勘误表如下：

可能会发生两种类型的故障：

情况一：
如果 WFE 指令放在内存中 32 位字的两个 MSB 中，在 WFE 执行周期或重新执行周期（从 ISR 处理程序返回时）发生的事件将导致代码执行不正确.

情况 2：
在 WFE 执行周期中发生的中断请求将导致错误的代码执行。这对于 WFE 重新执行周期也有效，同时从 ISR 处理程序返回

案例 2 不应该适用于您的情况，因为您说“由于我使用低功耗运行模式，因此未处理中断”。如果在 WFE 指令期间不能发生中断，则只有第一种情况中描述的故障可能会导致您的锁定。

情况 1 仅适用于 WFE 指令在内存中的 32 位字中处于某种对齐方式的情况。因此，如果您可以确保 WFE 指令永远不会出现在以这种方式对齐的代码中，那么您将不会遇到此故障。如果您的汇编器支持 align 指令，您可以使用它来实现这一点，如果汇编器不插入 NOP，则可能与标签和跳转一起使用。然而，勘误表中给出了一个更简单的解决方案作为“专用解决方法”：

将 WFE 指令替换为

     WFE
     JRA next
next:

这似乎通过在 WFE 指令之后放置相当于 2 字节 NOP 的内容来解决故障。我的猜测是故障导致 CPU 没有立即执行 WFE 指令之后的指令，而是在下一个 32 位世界开始时向前跳过两个字节到指令（如果有的话）。在跳过的空间中放置一个 2 字节的 NOP 意味着无论是否发生故障都无关紧要。

于 2016-04-04T21:26:06.623 回答
1

OP找到的解决方案：

我已经仔细阅读了几次勘误表（感谢罗斯里奇），这是主要思想：

一般的解决方案是通过适当的应用时序确保在 WFE 指令执行或重新执行周期期间不发生中断请求或事件。

于 2016-04-04T07:49:06.390 回答