脑洞大开，关于RTOS Trace一个重要的功能研究，系统出问题的时候，能不能回溯到各个任务的执行位置

eric2013

引出问题

众所周知，RTOS的IDE调试非常麻烦，出问题了也不方便锁定，经常出现几个任务不执行，或者仅空闲任务在跑，或者执行几次不执行了，等等，类似场景问题很多。

首先使用IDE很难锁定这种问题，因为很多时候不是不执行的那个任务出问题了。导致出问题了只能排查法，一个任务一个任务排查，而且还不容易复现问题，令人头疼。

解决办法思考：

今天想到一个思路，RTOS任务执行出问题后，能不能锁定此时此刻各个任务运行的位置，从而来方便我们锁定是那个任务执行导致的。感觉这是一个非常有价值的研究方向。

当前H7-TOOL的RTOS Trace支持了任务和通信组件执行情况监测和任务链表功能。面对实战性问题，这个Trace功能还不够，需要更加直接的手段。所以RTOS Trace下一步打算研究下这个功能。

skyshine

似乎要解析任务栈，这个有难度啊

eric2013

skyshine 发表于 2024-8-1 08:55
似乎要解析任务栈，这个有难度啊

对，要解析下任务栈。

byccc

eric2013 发表于 2024-8-1 09:24
对，要解析下任务栈。

监测到系统出现问题后，这个应该需要CPU停止运行，然后获取是否使用FPU，当前处于任务中还是中断里面，再进一步获取保持任务执行位置的栈值。

eric2013

byccc 发表于 2024-8-2 08:49
监测到系统出现问题后，这个应该需要CPU停止运行，然后获取是否使用FPU，当前处于任务中还是中断里面，再 ...

还在思考怎么实现更方便些。

eric2013

这几天脑子好用，准备重启下这个功能

xieyang__

支持硬汉,我有个思路不知道行不行：
出问题时，直接dump所有任务堆栈，类似于windows的minidup;
可以再通过h7tool还原现场；

eric2013

xieyang__ 发表于 2025-5-19 19:58
支持硬汉,我有个思路不知道行不行：
出问题时，直接dump所有任务堆栈，类似于windows的minidup;
可以再通 ...

可以的，我也有类似想法