cmbacktrace-integration
starsforks
How to install cmbacktrace-integration?
easyzoom/aix-skills/cmbacktrace-integration
$npx -y skills add easyzoom/aix-skills --skill cmbacktrace-integrationUse when integrating, porting, configuring, or debugging CmBacktrace on Cortex-M faults, stack traces, firmware metadata, fault handlers, or crash logs
SKILL.md
| 1 | # CmBacktrace Integration |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Use this skill to integrate CmBacktrace as a Cortex-M crash diagnosis tool. The key is to preserve fault context, provide correct firmware metadata, route output safely, and verify that backtraces map to the running ELF. |
| 6 | |
| 7 | ## When To Use |
| 8 | |
| 9 | Use this skill when: |
| 10 | |
| 11 | - The target is Cortex-M and the user wants automatic fault diagnosis or stack backtraces. |
| 12 | - The issue involves HardFault, fault handlers, register dumps, firmware name/version/hardware version, or crash logs. |
| 13 | - The project uses or plans to use CmBacktrace. |
| 14 | |
| 15 | Do not use this skill for non-Cortex-M faults. Use `embedded-fault-debug` or the architecture-specific debug skill instead. |
| 16 | |
| 17 | ## First Questions |
| 18 | |
| 19 | Ask for: |
| 20 | |
| 21 | - MCU/core, compiler, optimization level, and build flags. |
| 22 | - Fault handler code and whether the system resets immediately. |
| 23 | - Output backend for crash text: UART, RTT, flash, EasyLogger, shell, or custom. |
| 24 | - Firmware metadata values and where they are defined. |
| 25 | - Whether the ELF/MAP file matching the running image is available. |
| 26 | - Current fault output or absence of output. |
| 27 | |
| 28 | ## Integration Checklist |
| 29 | |
| 30 | 1. Integrate in the fault path. |
| 31 | Call CmBacktrace from the HardFault/fault handling path before reset and before clearing fault state. |
| 32 | |
| 33 | 1. Provide metadata. |
| 34 | Firmware name, hardware version, software version, and platform identifiers should be meaningful enough for field logs. |
| 35 | |
| 36 | 1. Keep output safe. |
| 37 | Crash output must not block forever, allocate heavily, or depend on services that may be corrupted. |
| 38 | |
| 39 | 1. Match symbols. |
| 40 | Ensure the saved crash output can be mapped to the exact ELF/MAP file used to build the flashed image. |
| 41 | |
| 42 | 1. Account for compiler behavior. |
| 43 | Optimization, frame pointer omission, link-time optimization, and stripped symbols can reduce backtrace quality. |
| 44 | |
| 45 | 1. Verify with a controlled fault. |
| 46 | Trigger a known null pointer or assert in a lab build, then confirm the report identifies the expected function. |
| 47 | |
| 48 | ## Porting Checks |
| 49 | |
| 50 | - Fault handler does not reset before CmBacktrace runs. |
| 51 | - Stack pointer and fault stack frame are still valid when called. |
| 52 | - Output route is initialized early or has a crash-safe fallback. |
| 53 | - RTOS task stack ranges are known if task-aware backtracing is expected. |
| 54 | - Watchdog timeout is long enough to emit crash data or is handled intentionally. |
| 55 | - Crash logs stored to flash do not erase unrelated data without approval. |
| 56 | |
| 57 | ## Common Failures |
| 58 | |
| 59 | - No output because UART/logger is not safe inside HardFault. |
| 60 | - Backtrace points to wrong functions because ELF does not match firmware. |
| 61 | - System resets before crash report completes. |
| 62 | - Optimized build produces shallow or confusing backtrace. |
| 63 | - Crash handler recursively faults while printing too much. |
| 64 | |
| 65 | ## Verification |
| 66 | |
| 67 | Before claiming CmBacktrace works: |
| 68 | |
| 69 | - State MCU/core, compiler, output backend, and firmware metadata. |
| 70 | - Confirm a controlled crash produces a report. |
| 71 | - Confirm the report maps to the expected function in the matching ELF. |
| 72 | - Confirm reset/watchdog behavior after report. |
| 73 | - State whether persistent crash storage is used and how data loss is avoided. |
| 74 | |
| 75 | ## Example |
| 76 | |
| 77 | User: |
| 78 | |
| 79 | ```text |
| 80 | 想在 Cortex-M 项目里接 cmbacktrace，HardFault 后能看到调用栈。 |
| 81 | ``` |
| 82 | |
| 83 | Agent: |
| 84 | |
| 85 | 1. Asks for MCU, compiler flags, HardFault handler, output backend, and matching ELF. |
| 86 | 1. Ensures CmBacktrace runs before reset and output is crash-safe. |
| 87 | 1. Uses a controlled fault to verify report generation and symbol mapping. |
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
