本篇目标：讲清 RTOS 调试的三层手段——日志、内核 Trace、硬件 Trace，以及 stp_rtos 实际用了什么。
一、为什么 RTOS 难调试
单线程程序断点一打、单步一走就清楚了。RTOS 的难点：
- 并发：多个任务交错跑，bug 只在特定时序出现；
- 时序敏感：打断点会改变时序，bug 消失（海森 bug）；
- 现场难抓：任务切换频繁，出问题时不知道是哪个任务、什么状态。
所以 RTOS 调试的核心是记录，而不是打断。
二、第一层：日志（LOG）
stp_rtos 移植了 easylogger，内核里到处是分级日志：
按模块（tag）+ 级别（level）过滤，是定位问题的第一手信息。代价是日志本身有开销，会扰动时序。
三、第二层：内核 Trace
不打断运行，只记录事件流，事后回放：
- SEGGER SystemView：记录任务切换、中断进出、API 调用，时间轴可视化，是 FreeRTOS/RT-Thread 生态的标配；
- RTOS Trace 链表：H7-TOOL 等工具直接读内核链表，展示就绪列表、挂起列表的实时状态；
- stp_rtos 的列表打印：配合 letter shell，
list thread遍历对象容器打印所有线程名和状态。
四、第三层：硬件 Trace
- DWT/ITM：Cortex-M 内置，周期计数器、数据观察点；
- ETM Trace：J-Trace + Ozone 抓指令级 trace，能还原“每条指令何时执行”，是抓偶发最坏延迟的终极手段；
- H7-TOOL 黑盒子：把故障现场自动存进专用内存，事后导出分析。
五、小结
- 日志 → 内核 Trace → 硬件 Trace，侵入性递增、信息量递增；
- 时序敏感的 bug 用“记录”而非“断点”；
- stp_rtos 用 easylogger + shell 列表打印，配合 SystemView/H7-TOOL 做外部 Trace。
核心一句话：RTOS 调试靠记录事件流，而不是打断执行。
