rtos-debug
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseRTOS 调试
RTOS Debugging
适用场景
Applicable Scenarios
- 固件运行了 RTOS(FreeRTOS、RT-Thread 或 Zephyr),需要查看任务状态。
- 怀疑任务栈溢出导致 HardFault 或异常行为。
- 需要检测死锁(所有任务都处于等待状态)。
- 需要查看队列、信号量等内核对象状态。
- 需要自动识别固件使用的 RTOS 类型。
- Firmware runs RTOS (FreeRTOS, RT-Thread, or Zephyr) and needs to check task status.
- Suspect task stack overflow causes HardFault or abnormal behavior.
- Need to detect deadlocks (all tasks are in waiting state).
- Need to view the status of kernel objects such as queues and semaphores.
- Need to automatically identify the RTOS type used by the firmware.
必要输入
Required Input
- 带符号的 文件路径。
ELF - 已运行的 GDB Server(OpenOCD 或 JLinkGDBServer),通过 指定 GDB 端口。
--port - 可选显式指定 RTOS 类型()。
--rtos freertos|rt-thread|zephyr
- Path to the signed file.
ELF - Running GDB Server (OpenOCD or JLinkGDBServer), specify the GDB port via .
--port - Optional explicit specification of RTOS type ().
--rtos freertos|rt-thread|zephyr
自动探测
Automatic Detection
- 通过 ELF 符号表自动判断 RTOS 类型:→ FreeRTOS,
vTaskStartScheduler→ RT-Thread,rt_thread_init→ Zephyr。k_thread_create - 不依赖 OpenOCD 的 RTOS awareness 功能,改用 GDB 直接读取 RTOS 内核数据结构。
- FreeRTOS 提供完整支持(任务列表、栈水位、队列),RT-Thread/Zephyr 提供基本任务列表支持。
- Automatically determine the RTOS type through the ELF symbol table: → FreeRTOS,
vTaskStartScheduler→ RT-Thread,rt_thread_init→ Zephyr.k_thread_create - Does not depend on OpenOCD's RTOS awareness function, instead uses GDB to directly read RTOS kernel data structures.
- Full support for FreeRTOS (task list, stack watermark, queues), basic task list support for RT-Thread/Zephyr.
执行步骤
Execution Steps
- 先阅读 references/usage.md 和 references/rtos-patterns.md,了解常见 RTOS 问题模式。
- 确保 GDB Server(OpenOCD 或 JLinkGDBServer)已在运行。
- 若不确定 RTOS 类型,先运行 scripts/rtos_debugger.py 的 模式。
--detect - 使用 查看任务列表和状态。
--tasks - 使用 检查各任务栈水位。
--stack-check - 使用 检查死锁特征。
--deadlock - 使用 查看队列和信号量状态。
--queues
- First read references/usage.md and references/rtos-patterns.md to understand common RTOS problem patterns.
- Ensure the GDB Server (OpenOCD or JLinkGDBServer) is running.
- If unsure of the RTOS type, first run the mode of scripts/rtos_debugger.py.
--detect - Use to view the task list and status.
--tasks - Use to check the stack watermark of each task.
--stack-check - Use to check for deadlock characteristics.
--deadlock - Use to view the status of queues and semaphores.
--queues
失败分流
Failure Diversion
- 当缺少 GDB 时,返回 。
environment-missing - 当没有可用的 时,返回
ELF。artifact-missing - 当 GDB 无法连接到 GDB Server 时,返回 。
connection-failure - 当 ELF 中未检测到 RTOS 符号时,返回 。
project-config-error - 当 GDB 可以连接但无法读取 RTOS 数据结构时,返回 。
target-response-abnormal - 当无法确定 RTOS 类型时,返回 。
ambiguous-context
- Returns when GDB is missing.
environment-missing - Returns when no available
artifact-missingis present.ELF - Returns when GDB cannot connect to the GDB Server.
connection-failure - Returns when no RTOS symbols are detected in the ELF.
project-config-error - Returns when GDB can connect but cannot read RTOS data structures.
target-response-abnormal - Returns when the RTOS type cannot be determined.
ambiguous-context
平台说明
Platform Notes
- 自带脚本使用 Python 标准库和 subprocess 调用 GDB,跨平台兼容。
- GDB Server 需要由用户或上游 skill(或
debug-gdb-openocd)预先启动。debug-jlink - RTOS 数据结构读取依赖 ELF 符号信息,Release 优化可能导致部分符号被优化掉。
- The built-in scripts use Python standard libraries and subprocess to call GDB, which is cross-platform compatible.
- The GDB Server needs to be pre-started by the user or upstream skills (or
debug-gdb-openocd).debug-jlink - Reading RTOS data structures depends on ELF symbol information; Release optimization may cause some symbols to be optimized out.
输出约定
Output Conventions
- 输出检测到的 RTOS 类型和版本(如果可获取)。
- 输出任务列表,包含任务名、状态、优先级和栈使用信息。
- 栈水位低于安全阈值时输出告警。
- 死锁检测结果以明确的是/否形式输出。
- 在 中更新
Project Profile字段。rtos
- Output the detected RTOS type and version (if available).
- Output the task list, including task name, status, priority, and stack usage information.
- Output an alarm when the stack watermark is below the safety threshold.
- Output deadlock detection results in a clear yes/no format.
- Update the field in
rtos.Project Profile
交接关系
Handover Relationships
- 当确认栈溢出时,建议使用 分析固件内存布局。
memory-analysis - 当需要更深入的单步调试时,交给 或
debug-gdb-openocd。debug-jlink
- When stack overflow is confirmed, it is recommended to use to analyze the firmware memory layout.
memory-analysis - When deeper single-step debugging is required, hand over to or
debug-gdb-openocd.debug-jlink