원클릭으로 Manus에서 모든 스킬 실행

b6-auto-debug

스타10

포크3

업데이트2026년 4월 22일 10:34

B6x 系统化烧录调试 — 编译 → 诊断 → 烧录 → RTT 监控。先理解失败原因，再采取行动。 TRIGGER when: 用户要求烧录、调试、下载固件、RTT监控、DAPLink/J-Link 操作、自动调试、flash编程、运行固件、连接失败、烧录失败、RTT无数据 DO NOT TRIGGER when: 仅编译请求（用 /b6-build）、纯代码审查、无硬件连接

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

XIAOMANSDK

XIAOMANSDK/B6x

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

관련 직업SOC

SOC 직업 분류 기준

소프트웨어 개발자컴퓨터 및 수학직·SOC 15-1252

파일 탐색기

3 개 파일

SKILL.md

readonly

이 저장소의 다른 Skills

같은 저장소

b6-build

XIAOMANSDK/B6x

编译 B6x SDK 工程 (Keil/GCC 自动检测)，解析编译日志，迭代修复错误和警告直到 0 ERROR 且 WARNING ≤ 5。 TRIGGER when: 用户要求编译、build、构建项目，修复编译错误/警告，检查编译结果，或提及 Keil/GCC 编译问题。 DO NOT TRIGGER when: 用户要求烧录/调试/下载固件（用 /b6-auto-debug）、纯代码审查、BLE协议问题、无硬件连接。

2026-05-1110

b6-library-recommend

XIAOMANSDK/B6x

根据应用需求推荐 BLE 库并生成 cfg.h 配置。 TRIGGER when: 用户询问 BLE 库选择、应该用哪个 BLE 库、库配置、连接数配置、RAM 配置、 BLE 角色配置（Master/Slave）、BLE_LITELIB/BLE_LARGELIB 设置、ANCS Client 支持、低功耗 BLE 配置、多连接配置、Mesh 配置。即使没有明确说 "推荐库"，只要涉及 BLE 库/连接数/角色的选择，也应使用此 skill。 DO NOT TRIGGER when: 用户要求创建新项目（用 /b6-create-project）、编译构建（用 /b6-build）、烧录调试（用 /b6-auto-debug）、代码审查（用 /b6-code-review）、硬件配置验证（用 /b6-validate-hardware）。

2026-05-1110

b6-translate-error

XIAOMANSDK/B6x

翻译 BLE 错误码，提供排查建议。 TRIGGER when: 用户询问 BLE 错误码含义、错误码翻译、0x 开头的错误代码、ATT_ERR/GAP_ERR/SMP_ERR 等错误常量、配对失败原因、连接错误、GATT 错误、BLE 返回码、协议栈错误。即使没有明确说 "翻译错误码"，只要出现 BLE 相关的数字错误码或错误常量名，也应使用此 skill。 DO NOT TRIGGER when: 用户要求创建新项目（用 /b6-create-project）、编译构建（用 /b6-build）、烧录调试（用 /b6-auto-debug）、代码审查（用 /b6-code-review）、硬件配置验证（用 /b6-validate-hardware）。

2026-05-1110

b6-validate-hardware

XIAOMANSDK/B6x

验证 B6x 硬件配置（引脚冲突/时钟/DMA/中断/Timer）是否符合芯片约束。使用此 skill 验证硬件配置的正确性。 TRIGGER when: 用户提及引脚配置、硬件验证、pin mux、外设冲突、ADC引脚、UART引脚、Timer引脚、DMA配置、中断优先级、时钟配置、检查配置冲突、验证硬件设置、引脚能否用作某功能。即使用户没有明确说"验证硬件"，只要涉及引脚/时钟/DMA/中断的配置检查，也应使用此 skill。 DO NOT TRIGGER when: 纯代码审查、编译错误修复、BLE协议问题、编写新驱动代码、解释函数作用、烧录程序。

2026-05-1110

b6-cmake-init

XIAOMANSDK/B6x

为现有 B6x SDK Keil 项目生成 CMakeLists.txt，实现 Keil → GNU/CMake 迁移。 TRIGGER when: 用户要求为现有项目生成 CMakeLists.txt、添加 GCC/CMake 支持、迁移 Keil 项目到 GNU 环境、创建 CMake 配置、转换 Keil 工程到 CMake、为项目添加 GCC 编译支持、支持 CI/CD 编译、 "帮我生成 CMakeLists.txt"、"添加 CMake 支持"、"迁移到 GCC"、"让项目支持 GCC 编译"。 DO NOT TRIGGER when: 用户要求创建全新项目（用 /b6-create-project）、编译现有项目（用 /b6-build）、烧录调试（用 /b6-auto-debug）、纯代码审查、BLE 协议问题、仅查看项目结构。

2026-04-2210

b6-code-review

XIAOMANSDK/B6x

B6x SDK 代码审查工具，检查 MISRA C 合规性、嵌入式最佳实践、BLE 规范和安全性问题。 TRIGGER when: 用户要求代码审查、code review、检查代码质量、检查 MISRA 合规性、检查嵌入式代码规范、检查 BLE 代码、安全审查、代码评审、看看代码有没有问题、检查这段代码。即使用户没有明确说"代码审查"，只要涉及检查 B6x 嵌入式代码的质量、安全性或规范性，也应使用此 skill。 DO NOT TRIGGER when: 用户要求编译构建（用 /b6-build）、烧录调试（用 /b6-auto-debug）、硬件配置验证（用 /b6-validate-hardware）、创建新项目（用 /b6-create-project）、纯 BLE 协议问题咨询。

2026-04-2210

name	b6-auto-debug
description	B6x 系统化烧录调试 — 编译 → 诊断 → 烧录 → RTT 监控。先理解失败原因，再采取行动。 TRIGGER when: 用户要求烧录、调试、下载固件、RTT监控、DAPLink/J-Link 操作、自动调试、flash编程、运行固件、连接失败、烧录失败、RTT无数据 DO NOT TRIGGER when: 仅编译请求（用 /b6-build）、纯代码审查、无硬件连接
user-invocable	true
allowed-tools	Read, Grep, Glob, Edit, Write, Bash
compatibility	Requires: embedded-debugger MCP server Hardware: DAPLink or J-Link debug probe Target: B61/B62/B63/B66 (ARM Cortex-M0+)

B6x 系统化烧录调试

铁律

没有诊断就不重试 — 理解失败原因后才采取行动

每个失败点都有诊断步骤。如果你没有收集证据，就不能提出重试。

参数

$ARGUMENTS: 项目路径（如 projects/bleUart）
设置变量 PROJECT 为项目名（路径最后一段）

适用场景

适用于任何硬件调试问题：

烧录失败
调试器连接失败
RTT 无输出
固件运行异常

尤其适用于：

"试了好几次都不行"（需要系统化诊断）
"之前能用的现在不行了"（先检查变化）
时间紧迫时（系统化比反复尝试更快）

阶段 0：预检查

在开始任何操作之前，验证前提条件。

0.1 确定目标项目

若 $ARGUMENTS 已提供，使用该路径作为项目目录
若未提供，询问用户项目路径后再继续
设置变量 PROJECT 为项目名（路径最后一段）

0.2 检查调试模式

读取项目的 src/cfg.h，确认 DBG_MODE 设置：

DBG_MODE	状态	操作
0	调试已禁用	停止，告知用户需要设置为 2
1	UART 模式	告知用户 RTT 不可用，询问是否切换
2	RTT 模式	通过，继续

0.3 检查环境

确认无其他调试工具占用（Keil 调试模式、J-Link Commander 等）
若有占用，提示用户关闭后重试

阶段 0 通过条件： 项目路径确定 + DBG_MODE == 2 + 无工具冲突

阶段 1：编译与提取

进入条件： 阶段 0 通过

1.1 编译项目

调用 /b6-build skill 完成编译，传入项目路径。

编译成功（0 ERROR）后继续；否则按 b6-build 的结果处理。

1.2 提取 RTT Control Block 地址

按 rtt-troubleshooting.md 第 1 节提取并验证 CB 地址。

1.3 编译失败诊断

现象	诊断步骤
编译错误	由 `/b6-build` 自动处理（最多 5 轮迭代）
RTT CB 地址未找到	按 `rtt-troubleshooting.md` "地址提取失败追溯链"排查

阶段 1 通过条件： 0 ERROR 编译成功 + 有效 RTT_CB_ADDR（0x2000xxxx）

阶段 2：连接与烧录

进入条件： 阶段 1 通过（有效 ELF + RTT_CB_ADDR）

2.1 连接调试器

首次连接：

{
  "probe_selector": "auto",
  "speed_khz": 1000,
  "connect_under_reset": true,
  "halt_after_connect": true
}

验证连接： 连接后立即调用 get_status(session_id) 确认状态。保存 session_id。

2.2 连接失败诊断

不要直接重试，先收集证据：

调用 list_probes() — 是否有调试器可见？

list_probes 结果	可能原因	下一步
无设备	USB 未连接、驱动问题	提示用户检查 USB 和驱动
有设备但连接失败	目标板未供电、SWD 接线问题	提示用户检查供电和接线
有设备且之前有会话	旧会话未释放	`disconnect` 旧会话后重试

仅在诊断完成后，执行一次重试：
- 调用 disconnect(session_id) 清理旧会话
- 重新 connect

2.3 烧录固件

{
  "session_id": "$SESSION_ID",
  "file_path": "build/elf/$PROJECT.elf",
  "format": "auto",
  "reset_after_flash": false,
  "attach_rtt": false
}

验证烧录： 调用 get_status(session_id) 确认目标处于 halted 状态。

2.4 烧录失败诊断

现象	诊断步骤
ELF 文件不存在	回到阶段 1 重新编译
烧录报错	先 `flash_erase(erase_type: "all")`，再重试烧录
目标未 halt	调用 `halt(session_id)` 强制停止

阶段 2 通过条件： 固件已烧录 + get_status 确认目标 halted + session_id 有效

阶段 3：RTT 激活

进入条件： 阶段 2 通过（固件已烧录，目标 halted）

3.1 附加 RTT

使用阶段 1 提取的地址手动附加：

{
  "session_id": "$SESSION_ID",
  "control_block_address": "$RTT_CB_ADDR"
}

验证附加： 调用 rtt_channels(session_id) 确认通道可见。

3.2 RTT 附加失败诊断

不要更换地址或反复附加，按 rtt-troubleshooting.md 第 2 节排查。

3.3 复位并运行

{
  "session_id": "$SESSION_ID",
  "reset_type": "hardware",
  "halt_after_reset": false
}

验证运行： 调用 get_status(session_id) 确认目标处于 running 状态。

如果仍处于 halted：调用 run(session_id) 强制运行

阶段 3 通过条件： rtt_channels 可见 + get_status 确认目标 running

阶段 4：监控与诊断

进入条件： 阶段 3 通过（RTT 通道可见，目标 running）

4.1 读取 RTT 输出

循环读取 RTT 日志：

{
  "session_id": "$SESSION_ID",
  "channel": 0,
  "max_bytes": 2048,
  "timeout_ms": 3000
}

停止条件：

用户明确要求停止
连续 5 次读取均无数据

4.2 无数据诊断

连续 3 次无数据时，不要继续空读，按 rtt-troubleshooting.md 第 3 节追溯排查。

阶段 4 结束条件： 用户要求停止，或诊断发现目标异常

三次失败升级

按 hardware-escalation.md 执行升级排查和架构质疑。

红旗 — 看到这些想法时停止

想法	为什么禁止
"跳过编译直接烧录旧固件"	固件与代码不同步，调试结果不可靠
"烧录失败就直接重试"	必须先诊断：连接状态？目标 halted？ELF 有效？
"用 sleep 等待就绪"	必须用条件检查：get_status、rtt_channels
"再试一次"（已失败 2 次以上）	3 次失败 = 升级排查根因，不重试

验证门控: 每个阶段通过时，必须使用 /b6_verification-before-completion 的证据模板输出验证结果，然后才能声称该阶段通过。

RTT 相关红旗见 rtt-troubleshooting.md 第 4 节。

常见自我辩解

借口	现实
"问题简单，直接重试就行"	简单失败也有根因。诊断比盲目重试更快。
"没时间诊断，先烧了再说"	系统化诊断花 30 秒；反复盲试花 10 分钟。
"sleep 2 秒应该够了"	任意延时不可靠。检查实际条件。
"CB 地址没变过"	代码变更会移动符号。每次编译后都从 map 文件重新提取。
"RTT 附加失败，固件肯定有问题"	RTT 附加失败有很多原因：时机、CB 地址、目标状态。先诊断。
"调试器应该没问题"	用 `list_probes()` 确认。假设浪费时间。
"用 run_firmware 一步到位"	手动分步操作 + 指定 CB 地址才是可靠方法。
"第 3 次一定能成"	3 次失败说明存在系统性问题。调查，不要重试。

条件等待技术

原则： 用实际条件验证替代任意延时。每个操作后验证真实状态。

操作	旧做法	新做法
连接调试器后	sleep(1-2)	`get_status(session_id)` 验证已连接
烧录完成后	假设成功	`get_status(session_id)` 验证目标 halted
RTT 附加后	假设已附加	`rtt_channels(session_id)` 验证通道可见
复位运行后	sleep(1)	`get_status(session_id)` 验证目标 running
RTT 读取	假设有数据	`rtt_read` 自带 timeout_ms（已是条件等待）

超时限制： 每个条件验证在 5 秒内完成。超时视为失败，进入诊断流程。

速查表

阶段	关键操作	通过条件	失败升级
0. 预检查	检查 DBG_MODE、关闭冲突工具	DBG_MODE==2，无冲突	告知用户，停止
1. 编译提取	/b6-build，grep RTT CB 地址	0 ERROR，有效 0x2000xxxx	检查编译配置、RTT 源文件
2. 连接烧录	connect → get_status → flash → get_status	固件已烧录，目标 halted	检查探针、USB、SWD、ELF
3. RTT 激活	rtt_attach → rtt_channels → reset → get_status	通道可见，目标 running	检查 CB 地址、DBG_MODE
4. 监控诊断	rtt_read 循环	用户停止或 5 次无数据	检查目标状态、RTT 结构

MCP 工具调用序列（正常流程）

list_probes → connect → get_status → flash_program → get_status →
rtt_attach(CB_ADDR) → rtt_channels → reset → get_status → rtt_read(循环)

注意事项

DBG_MODE 必须设置为 2（RTT 模式）在项目 src/cfg.h 中
每次编译后从新 map 文件提取 RTT CB 地址，不缓存旧地址
建议在烧录前关闭其他调试工具（Keil 调试模式、J-Link Commander 等）
session_id 在整个调试会话中保持不变，妥善保存