我在我的微控制器中有一个看门狗，如果不被“踢”，它会重置处理器。我的应用程序运行一段时间后会重置，因为看门狗没有被“踢”。如果我逐步执行程序，它就能正常工作。
有哪些调试方法？
编辑： 结论： 我找到错误的方法是使用看门狗面包屑。
我使用的是具有高和低ISR向量的PIC。高向量应该处理LED矩阵，而低向量应该处理定时器滴答声。但我把两个ISR处理程序都放在了高向量中。因此，当我禁用LED矩阵ISR且需要服务的定时器滴答声ISR时，处理器将卡在低ISR中处理定时器滴答声，但定时器滴答声处理程序不存在。
面包屑将我的搜索范围限制在处理LED矩阵的函数上，特别是禁用LED矩阵中断。
在代码中添加一个未初始化的全局变量，并在主要函数调用之前和之后设置不同的值。
在 main 函数开头设置断点。
当处理器重置时，全局变量仍将保留其最后一个被设置的值。继续添加这些“面包屑”以缩小问题所在的函数范围。
我会使用额外的输出引脚，在代码中适当的位置设置高电平然后低电平来限制我正在查找的范围。然后，我会在数字示波器或逻辑分析仪上跟踪它。这相当于另一个帖子提到的面包屑方法，但您将能够更好地与复位脉冲进行时间相关性。
在优秀的被接受答案（https://dev59.com/onRB5IYBdhLWcg3wUFvB#661900）的基础上，为了我的应用程序，我进一步研究了看门狗复位后检查RAM的方法。由于这段文字对于评论来说太长了，所以我将其作为一个额外的答案添加：
我们的应用程序是由自定义引导程序前缀的，该引导程序提供了一些功能，例如OTA固件更新。通过将此引导程序的初始堆栈指针设置为RAM末尾之前的1 kb，足够的堆栈仍然留在RAM中，以便在主固件被看门狗重置时重构回溯。然后，引导程序需要识别重启原因是看门狗，并将RAM的最后1 kb复制到某个指定的闪存区域，从中可以恢复它。
重构回溯有点麻烦，因为没有PC可以从中开始，因此实际上应该从底部向顶部手动展开堆栈，并且可能需要进行一些有教育意义的猜测，以确定应用程序停止的位置。（这不一定是看到过时数据并且展开失败的地方！）
这种方法帮助我系统地找出了一个非常零散的问题。要在堆栈上记录其他“面包屑”，只需插入诸如：
__attribute((unused)) volatile uint32_t _state[4];
_state[0] = 0x57a11ed; // magic value to aid manual unwinding
_state[1] = RCC->CSR;
_state[2] = count++; // maybe we're in a runaway loop?
// etc.
反复质疑你所做出的每一个假设：
同时，思考“逐步执行”和单独运行之间的差异；时间限制肯定很重要。
strace（选项-p）附加到正在运行的进程上，观察它何时停止向打开的文件描述符/dev/watchdog写入。-e筛选strace的输出。