这是一个创建于 2324 天前的主题，其中的信息可能已经有所发展或是发生改变。
第一次提问，不知道这里有没有同行，暂且抛出问题吧。
对于嵌入式操作系统来说，系统死机是最严重的问题，之前遇到的死机问题大部分都是调试阶段遇到的，这种其实还是蛮容易解决的，大部分都可以通过单步调试解决的。我认为的一点是，对于软件发布后，客户使用阶段遇到的系统死机导致的功能异常，此种问题往往我们这边的经验是尝试通过复现的方法来调查，但对于极低概率发生的问题，复现本身就是一个很痛苦的过程，所以，有没有什么方法，可以记录下系统死机前的代码执行路径呢？
我们用的 32 位单片机，有相应的 EIPC 指针，可以记录进异常中断前的 PC 值，但这肯定不够。有这方面的大神出来讨论下吗？
对于嵌入式操作系统来说，系统死机是最严重的问题，之前遇到的死机问题大部分都是调试阶段遇到的，这种其实还是蛮容易解决的，大部分都可以通过单步调试解决的。我认为的一点是，对于软件发布后，客户使用阶段遇到的系统死机导致的功能异常，此种问题往往我们这边的经验是尝试通过复现的方法来调查，但对于极低概率发生的问题，复现本身就是一个很痛苦的过程，所以，有没有什么方法，可以记录下系统死机前的代码执行路径呢？
我们用的 32 位单片机，有相应的 EIPC 指针，可以记录进异常中断前的 PC 值，但这肯定不够。有这方面的大神出来讨论下吗？
 |
1
GPIO 2018-07-20 16:47:14 +08:00
关注，但是一般 RTOS 都没有类似于 core dump 的文件，确实很难分析诶。
|
 |
2
Ediacaran 2018-07-20 17:30:46 +08:00  1
如果看门狗有中断的话，可以把整个 RAM 都输出出来。然后对照着编译生成的 MAP 文件，找各个任务的堆栈和全局变量的值
|
Select Language