【问题标题】:Hardfault on Cortex M0 cannot be tracked down [closed]无法追踪 Cortex M0 上的硬故障 [关闭]
【发布时间】:2021-12-18 01:07:51
【问题描述】:

我很难追踪我的 nrf51822 板上随机发生的硬故障。

我可以在硬故障处理程序上设置断点,但堆栈信息并没有多大用处。 我可以围绕导致硬故障的指令进行单步调试,并且绝对没有任何东西可以触发此类故障。在下面的示例中,PRstrcpy 只是两个绝对合法地址之间的副本。 其他症状:

  • 堆栈仍有足够的空间。
  • 没有待处理的 IRQ(我检查了 NVIC 寄存器)
  • 如果我移动断点,或进行完整的单步调试,硬故障可能发生在代码的任何其他位置
  • 我现在使用 -o0 进行编译以进行 SWD 调试。使用更高的优化进行编译可以解决(或更好地隐藏)它。
  • 如果我使用相同的 flash 映像,无论是否编译都会发生这种情况
  • 将代码更改为最微小的位,也会导致硬故障随机移动、移动到完全不相关的位置或消失。
  • 在具有相同设置和工具链的其他机器上编译代码也会导致硬故障发生随机变化。

对调试有什么想法吗?

下面是堆栈跟踪:

Thread #1 <main> (Suspended : Breakpoint)   
    HardFault_Handler() at 0x34976  
    <signal handler called>() at 0xfffffff9 
    PRstrcpy() at kcs_stdlibs.c:94 0x1aa66  
    PrintConfigInfo() at Startup.c:36 0x15256   
    0xfffffffe  

【问题讨论】:

  • 我猜你有一个异步错误。所以这个问题可能在过去的某个时候发生过,但只是在以后才出现。

标签: cortex-m fault


【解决方案1】:

我在我的案例中发现了问题,这是一些不同且难以调试的问题。 我有一些闪存写指令,它们会覆盖上面的闪存区域。只有在使用低优化值时,这些闪存区域才会托管合法指令。 所以我的代码在运行时被即时修改。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-09-09
    • 2017-06-20
    • 2016-12-18
    • 2020-11-12
    • 2023-04-11
    相关资源
    最近更新 更多