您好！
我们一直在努力解决一个非常奇怪的硬故障、这种故障要么在相同条件下的一段时间后发生、要么从未发生(取决于编译输出)。
我们投资了一款用于 Cortex M 的 J-Trace Pro 并执行了指令跟踪、我们观察到了最奇怪的行为。 在某个指针处、在中断处理程序中、PC 不仅在一条简单的寄存器加载指令后递增、而且会跳转到代码的完全不同部分。
您是否经历过这样的行为？ 勘误表中是否有我可能遗漏的内容？
请在下面找到进入硬故障处理程序时指令跟踪的屏幕截图：
您好！
FAULTSTAT 不会提供更多信息、因为它与执行序列(无效的存储器访问)一致。 您可以浏览附加图片中的不同位。
是的 ，MasterFailureTask:DetectNewMasterFailures ()是我们实现的，但它从未在任何中断上下文中使用。 与此类似、我的同事观察到了相同的行为、但执行从 USBIRQHandler 跳转到主函数开头仅实例化一次的变量的构造函数、而不是 SysTickIRQHandler。
我没有任何指示 PC 加载了另一个值、但常量似乎是无效执行跳转总是在中断上下文中发生。
我们还监视了 RAM 中的中断矢量、但它没有从最后一个中断寄存器更改为错误发生。
在尝试测试软件的其他功能时，我们现在观察到一种新的故障，NOCP！ 这是否相关？
我们的编译器具有-float_support=FPv4SPD16选项
您好 Ralph、
正如我说过的、选项是 -float_support=FPv4SPD16 
以下是地址0x7932之后的指令： 
我给您的 SP 地址是我自己的分析、也许是错误的、在 SysTick 中断是周期性的时、不可能在这个精确的时刻放置一个断点。
下面是一个包含更多信息的新屏幕截图、您在 SP 周围有所有 RAM、在我们的自定义硬故障处理程序中、我们存储堆栈式帧(右上角)、您可以看到 LR=0x4D77、您还可以看到所有寄存器 R0-R15。 不管怎样、如果您看一下跟踪指令时序、我怀疑它错过了任何指令。 
我自己需要注意的是：这是软件版本3563、其中跟踪引脚配置为 GPIO_Strength _12mA。
您好！
首先、感谢您的支持和所有评论、我将尝试全部回答。
是的、错误发生在多个单元上。 但是、尽管我们遵循了所有系统设计指南、但我们不能排除硬件设计中的任何错误。 很难确定根本原因是否仅与硬件/软件相关、或两者之间是否有一点点关系。
关于您的推送/弹出备注、它对应于以下代码。 两个函数已关联、因此两个推/弹出对。 为了使用 TivaWare 中的 IntRegister 函数、我们必须实现包装程序、因为您需要传递函数指针、但要在 C++中执行非静态方法、您还需要该对象。 虽然 J-Trace 的时序看起来很奇怪、但我不确定它意味着我们丢失了布线中的任何指令、它可能会链接到 Chester 所述的 WFI 指令。 
我可以删除 WFI 指令和中断嵌套。 但是、正如我在开始时提到的、仍然会有一个硬故障、但如果没有与故障相同的跳转、甚至没有与给定二进制故障相同的源、则始终是相同的、但取决于二进制。
此致、
Matthieu
您好 Ralph、
下面是 SysTick 函数的完全反汇编(不带包装程序)： 
我还向您提供.out 的完整符号、以便您还可以根据需要浏览反汇编。 (必须以.7z 格式)e2e.ti.com/.../Blood.7z
我们使用 IntRegister 是因为它更容易实现通用驱动程序、但我们的调度程序非常简单、与 RTOS 不同、因此该线程不适用于我们。
此致、
Matthieu
我还测试了 Chester Idea 并删除了 WFI 指令、我们的程序运行一整晚、没有任何故障。 所以、我在数据表中做了一些挖掘、我看到了这个部分、尤其是"注意"一段。
我认为这可能与观察到的问题有关。 你怎么看？
我还检查了时钟门控、并使用 SysCtlPeripheralEnable 函数设置 RCGC 寄存器、我们从未启用自动时钟门控、因此即使在 WFI 指令期间外设也应计时。 因此、我不明白为什么这会触发硬故障。 但是、当我们实施了更多与硬件相关的功能并在中断中添加了一些浮点计算时、我们确实开始观察到了这个问题、因此这似乎与我们的问题完全相关。
我还执行了一个测试、在这个测试中、我放置了 WFI 指令、但是也使用 SysCtlPeripheralSlepEnable 函 数设置 SCGC 寄存器、并且使用 SysCtlPeripheralClockGating 函数启用了自动时钟门控。 该软件也已运行数小时、没有任何故障。
如果您认为这与我们的问题相关、您能否向我们提供有关微控制器在这些不同情况下实际发生的情况的详细信息、以帮助我们更好地了解问题？
此致、
Matthieu
[引用 USER="Chester Gillon">将尝试为 TM4C129创建一个程序、该程序大部分时间处于睡眠状态(使用 WFI)、只是使用计时器中断以高速率唤醒、 查看是否会导致故障。所附工程用于 TM4C129XNCZAD、在中断处理程序中发现该工程会生成硬故障。 测试概述如下：
*@详细说明测试组织为裸机程序、其中： * a：主线程使用 wfi 指令旋转循环、将处理器置于睡眠状态 、* 并且只增加全局变量、甚至是由中断唤醒的时间。 * b. SysTick 计时器处理程序、用于切换某些 LED、其中 SysTick 计时器以固定速率运行。 * c.切换某些 LED 的 timer0处理程序。 计时器周期经过一个范围、尝试"拍频 "* 与 SysTick 计时器配合使用。 * d.每次调用 LED 时、中断处理程序都会向其 GPIO 写入数据 、并更改 LED 状态* 以较低的速率提供可见的闪存。 * * 目标板是"用于 Tiva C 系列的 mikromedia 5"
只有在连接调试器(XDS200)并在 CCS 10.1.1下运行时、才会出现硬故障。
如果在 CCS 下启动调试会话、则在运行后的12秒内会进入硬故障。 硬故障发生位置的示例(使用 CCS/TM4C1294KCPDT 中的 GEL 脚本：如何在异常处理程序中使堆栈解除缠绕？ 要在发生硬故障后松开堆栈、请执行以下操作)：
当发生硬故障时、违规指令始终位于地址 0x2AC。 当该指令被执行时、R8的常量值应为0x20000200、但是寄存器 R8在发生硬故障时的值为0x0。 NVIC_FAULT_STAT 寄存器为0x00008200、其中 NVIC_FAULT_STAT_BFARV (总线故障地址寄存器有效)和 NVIC_FAULT_STAT_PRECISE (精确数据总线错误)位置位。 NVIC_FAULT_ADDR 寄存器为0x0138EEA5、但是从反汇编和寄存器转储中、似乎没有正在访问地址 0x0138EEA5的指令。
此外、这些测试通过一系列值扫描 timer0的周期、当发生硬故障时 、timer_period 通常为5925、但当 发生硬故障时、可以看到5923的值。
2、如果目标上电后重启、保持 XDS200连接、但未运行调试会话、则测试继续运行。 在两次跑步中离开1小时或4小时。 目标运行时、连接调试器、然后恢复运行。 在几秒钟内发生了硬故障。
这表明由于调试会话被连接而启用 DAP 时、使用 wfi 将处理器置于睡眠状态的某些交互。
我还没有尝试更改内容、以查看启用 DAP 后问题会如何解决。
使用的 TM4C129XNCZAD 的 DID0值为0x100A0002、这意味 着器件版本3。
[引用 user="Ralph Jacobi">我将 CCS 项目连接到 WFI 已完成对齐的位置。 我要注意的一点是、根据我们的一位专家的建议、我们确实在 WFI 命令之后添加了两个 NOP、他说这是基于我们 Hercules 器件的良好做法。 解决方案不需要这种情况、 但这是一个很好的做法。搜索找到 TI 应用手册，了解 在 SimpleLink
MSP432ARM
Cortex-M4微控制器上正确睡眠和中断使用的 Cortex-M MSP432 ，该应用手册介绍了使用 数据同步边界(DSB)指令刷新数据存储器的必要性 传输管线以避免 意外行为。
和 ARM 应用手册321存储器边界指令的 ARM Cortex-M 编程指南 第3.3节架构要求包含以下内容：
[报价]睡眠
在暂停执行以进入睡眠模式之前、处理器硬件不需要消耗任何挂起的存储器活动。 因此、如果使用的睡眠模式可能影响数据传输、软件必须通过添加隔离指令来处理这一问题。 应使用 DSB 来确保在执行 WFI 或 WFE 指令之前没有未完成的存储器事务。[/QUESP]根据该循环 、我更改了 EK-TM4C129EXL 的示例、以便在 wfi 指令之前添加 DSB：
对于(；)
｛
ASM (" DSB")；
ASM (" wfi")；
num_wakeups++；
｝
从反汇编中、wfi 不是32字节对齐的：
$C$L9： 00000574：F3BF8F4F DSB SY 00000578：BF30 WFI 153. num_wakeups++； 0000057a：6808 LDR R0、[R1] 0000057c：1C40 添加了 R0、r0、#1 0000057e：6008 结构 R0、[R1] 154 } 00000580：E7F8 B $C$L9
仅插入 DSB 指令、即不添加 wfi 指令的显式对齐、也不添加任何尾随 NOP、硬故障就不再发生。
不确定添加 DSB 是否已修复根本原因、或只是更改了时序来屏蔽问题。
切斯特、您好！
这是一个有趣的消息。 我即将在这篇文章中写下这篇文章、因为我将修复分发给了我们的软件团队、不幸的是、我的两位同事发生了硬故障、我们的分析表明它们与同一个问题相关。 因此、WFI 指令32位对齐似乎不足以解决问题。
我还看到了以下帖子：
https://stackoverflow.com/questions/47022456/why-is-an-isb-needed-after-wfi-in-cortex-m-freertos
我还发现以下建议：
"在执行 WFI 或 WFE 指令之前、应使用 DSB 来确保没有未完成的存储器事务。 "
和许多解释、请参阅《存储器边界指令的应用手册321 ARM Cortex-M 编程指南》 
我们的大多数团队今天都在休假、但我们将在明年年初尽快执行新测试。
祝你圣诞节快乐！
Matthieu Tsardivon
[引用 user="Chester Gillon">不确定添加 DSB 是否已修复根本原因、或只是更改了时序来屏蔽问题。 ARM 应用手册321显示 DSB 的架构要求是确保在停止时钟之前已完成缓冲写入：
要尝试并了解 DSB 是否解决了根本原因：
a.下载 EK-TM4C129EXL 的原始程序失败。
b.当程序在 main()的开头停止时，使用调试器将 NVIC_ACTLR 寄存器中的 NVIC_ACTLR_DISWBUF 位置位，从而禁用写入缓冲器。
仍然出现硬故障。 也就是说、不要相信添加 DSB 可以解决根本原因、而只是更改了时序。