embedded-debug-entry
starsforks
How to install embedded-debug-entry?
easyzoom/aix-skills/embedded-debug-entry
$npx -y skills add easyzoom/aix-skills --skill embedded-debug-entryUse when triaging embedded device, MCU, firmware, board bring-up, flashing, serial log, RTOS, bootloader, low-power, or peripheral debug requests
SKILL.md
| 1 | # Embedded Debug Entry |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Use this skill as the first stop for embedded debugging. The agent should classify the target, failure phase, access method, toolchain, and risk level, then route to the narrowest specialized skill instead of guessing from incomplete context. |
| 6 | |
| 7 | ## When To Use |
| 8 | |
| 9 | Use this skill when: |
| 10 | |
| 11 | - The user reports an embedded device, MCU, board, firmware, RTOS, bootloader, or peripheral issue. |
| 12 | - The architecture or debugging path is unclear. |
| 13 | - The task might involve flashing, serial logs, SWD/JTAG, UART, ADB, bootloaders, low power, or hardware signals. |
| 14 | |
| 15 | Do not use this skill when the user already named a more specific skill path, such as Cortex-M HardFault, 8051 timer, RISC-V trap, or embedded Linux SSH login. |
| 16 | |
| 17 | ## First Questions |
| 18 | |
| 19 | Ask only what is needed to route: |
| 20 | |
| 21 | - Target type: MCU, embedded Linux device, mixed SoC, module, or unknown board. |
| 22 | - Architecture or chip family: Cortex-M, Cortex-R, RISC-V, 8051, Linux-capable ARM, or unknown. |
| 23 | - Failure phase: cannot connect, cannot flash, no boot, crash/fault, no logs, peripheral failure, RTOS issue, bootloader issue, low-power issue. |
| 24 | - Available access: SWD/JTAG, serial UART, SSH, ADB, Telnet, local console, logic analyzer, oscilloscope, or vendor tool. |
| 25 | - Toolchain and artifacts: ELF/HEX/MAP, firmware log, programmer output, schematic, boot log, or fault dump. |
| 26 | |
| 27 | ## Routing Guide |
| 28 | |
| 29 | Use the most specific path: |
| 30 | |
| 31 | | Symptom or target | Prefer | |
| 32 | | --- | --- | |
| 33 | | Cortex-M MCU, SWD/JTAG, HardFault, startup | `cortex-m-debug` | |
| 34 | | Cortex-R5/R4/R7, TCM, MPU, lockstep, safety core | `cortex-r5-debug` | |
| 35 | | 8051/51/STC/Nuvoton/Silabs C8051 | `8051-mcu-debug` | |
| 36 | | RISC-V MCU, OpenOCD/GDB, trap, CSR | `riscv-mcu-debug` | |
| 37 | | Embedded Linux login before debugging | `embedded-linux-login-debug` | |
| 38 | | OpenOCD/J-Link/ST-Link probe, SWD/JTAG attach | `openocd-jlink-stlink-debug` | |
| 39 | | Flash/download/verify/connect failure | `mcu-flashing-debug` | |
| 40 | | UART boot log, serial console, 乱码, no logs | `embedded-serial-log-debug` | |
| 41 | | Crash, exception, trap, fault, stack corruption | `embedded-fault-debug` | |
| 42 | | GPIO/UART/SPI/I2C/PWM/ADC bring-up | `embedded-peripheral-bringup` | |
| 43 | | Sensor driver, IMU, I2C/SPI sensor data | `sensor-driver-integration` | |
| 44 | | QSPI/OSPI flash, XIP, memory-mapped boot | `qspi-xip-flash-debug` | |
| 45 | | FreeRTOS kernel: tasks, heap, tick, ISR API | `freertos-kernel-debug` | |
| 46 | | Zephyr devicetree, Kconfig, west, drivers | `zephyr-integration` | |
| 47 | | RT-Thread BSP, FinSH, device framework, DFS | `rt-thread-integration` | |
| 48 | | General RTOS scheduling, stacks, priorities | `rtos-debug` | |
| 49 | | STM32 HAL/LL, CubeMX, clocks, DMA, NVIC | `stm32-hal-ll-integration` | |
| 50 | | ESP-IDF, sdkconfig, partitions, NVS, Wi-Fi | `esp-idf-integration` | |
| 51 | | Nordic nRF Connect SDK, BLE, DFU, Partition Mgr | `nrf-connect-sdk-integration` | |
| 52 | | BLE GATT services, characteristics, MTU, pairing | `ble-gatt-integration` | |
| 53 | | Bootloader, app jump, upgrade state | `bootloader-debug` | |
| 54 | | MCUboot image slots, signing, swap, rollback | `mcuboot-integration` | |
| 55 | | OTA package, transport, validation, activation | `ota-update-integration` | |
| 56 | | Sleep, wakeup, current consumption, lost debug | `low-power-debug` | |
| 57 | | Power, reset, clock, pins, board-level signals | `hardware-interface-debug` | |
| 58 | |
| 59 | ## Workflow |
| 60 | |
| 61 | 1. Classify before acting. |
| 62 | Do not start with code edits, reflashing, or resets until the target and failure phase are known. |
| 63 | |
| 64 | 1. Route to one primary skill. |
| 65 | If multiple skills apply, pick the one closest to the current blocker. Example: "cannot flash Cortex-M" starts with `mcu-flashing-debug`, not general Cortex-M logic. |
| 66 | |
| 67 | 1. Collect minimal evidence. |
| 68 | Ask for the smallest artifact that proves the current state: programmer error, serial log, GDB register dump, schematic snippet, or tool output. |
| 69 | |
| 70 | 1. Preserve safety boundaries. |
| 71 | Treat erase, option bytes, boot config, security bits, fuses, production data, and power changes as explicit-approval actions. |
| 72 | |
| 73 | 1. Summarize the route. |
| 74 | Tell the user which path you selected and why before continuing with detailed debug instructions. |
| 75 | |
| 76 | ## Verification |
| 77 | |
| 78 | Before moving into a specialized workflow: |
| 79 | |
| 80 | - State target class, architecture, failure phase, available access, and selected skill. |
| 81 | - State what evidence is already available and what is still missing. |
| 82 | - Confirm no destructive operation has been recommended without approval. |
| 83 | |
| 84 | ## Common Failures |
| 85 | |
| 86 | - Treating every embedded issue as a firmware code problem. |
| 87 | - Asking for every possible tool output before choosing a debug path. |
| 88 | - Starting with flash erase when the failure is actually serial wiring or reset. |
| 89 | - Debugging application logic before proving the target boots and the image matches. |
| 90 | - Mixing Linux device login workflows with MCU bare-metal workflows. |
| 91 | |
| 92 | ## Example |
| 93 | |
| 94 | User: |
| 95 | |
| 96 | ```text |
| 97 | 板子起来以后没日志，也不知道是不是程序没跑。 |
| 98 | ``` |
| 99 | |
| 100 | Agent: |
| 101 | |
| 102 | 1. Asks for chip |
People who liked this also viewed
6 picksType
- azure-diagnosticsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deploySkillsJul 2026
- systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesSkillsJul 2026
- safe-debugRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training SkillsMay 2026
- explore-runRigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subseSkillsMay 2026
- minimal-run-and-auditRigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation SkillsMay 2026
- insforge-debugUse when diagnosing problems in an InsForge project — reactive failures (SDK error object, HTTP 4xx/5xx, gateway timeout 502/503/504, edge function failure or timeout, login/OAuth/auth errors, RLS denSkillsJul 2026
