大佬教程收集整理的这篇文章主要介绍了c – 当Cortex-M3进入硬故障时如何保留堆栈跟踪?,大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。
>基于Cortex-M3的μC
> gcc-arm cross toolchain
>使用C和C.
> FreeRtos 7.5.3
> Eclipse Luna
> Segger Jlink与JLinkGDBServer
> Code Confidence FreeRtos debug plugin
使用JLinkGDBServer和eclipse作为调试前端,在逐步执行代码时总是有一个很好的堆栈跟踪.当使用COde Confidence freertos工具(eclipse插件)时,我也看到当前没有运行的所有线程的堆栈跟踪(没有该插件,我只看到活动线程的堆栈跟踪).到现在为止还挺好.
但现在,当我的应用程序陷入严重错误时,堆栈跟踪将丢失.
好吧,我知道如何找出导致硬错误的代码地址的技术(见here).
但与完全堆栈跟踪相比,这是非常糟糕的信息.
好吧,有时候当遇到硬错误时,无法保留堆栈跟踪,例如当堆栈被错误的代码破坏时.但是如果堆栈是健康的,我认为获得堆栈跟踪可能是可能的(不是吗?).
我认为在硬错误中丢失堆栈跟踪的原因是,堆栈指针会被Cortex-M3架构自动从PSP切换到MSP.现在有一个想法,(可能)将MSP设置为之前的PSP值(可能还需要做一些额外的堆栈预处理?).
编辑2015-07-07,添加了更多详细信息.
__attribute__((optimize("O0"))) static void checkHardfault() { volatile uint32_t* varAtOddAddress = (uint32_t*)-1; (*varAtOddAddress)++; }
当进入checkHardfault()时,我的stacktrace看起来很像这样:
gdb-> BACktrace #0 checkHardfault () at Main.cxx:179 #1 0x100360f6 in GetOneEvent () at Main.cxx:185 #2 0x1003604e in executeMainLoop () at Main.cxx:121 #3 0x1001783a in vMainTask (pvParameters=0x0) at Main.cxx:408 #4 0x00000000 in ?? ()
当遇到hardfault(at(* varAtOddAddress);)并发现自己在HardFault_Handler()内部时,stacktrace是:
gdb-> BACktrace #0 HardFault_Handler () at Hardfault.c:312 #1 <signal handler called> #2 0x10015f36 in prvPortStartFirstTask () at freertos/portable/GCC/ARM_CM3/port.c:224 #3 0x10015fd6 in xPortStartscheduler () at freertos/portable/GCC/ARM_CM3/port.c:301 BACktrace stopped: prevIoUs frame inner to this frame (corrupt stack?)
以上是大佬教程为你收集整理的c – 当Cortex-M3进入硬故障时如何保留堆栈跟踪?全部内容,希望文章能够帮你解决c – 当Cortex-M3进入硬故障时如何保留堆栈跟踪?所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。