embedded-debug

Parse crash outputs and decode stack traces from ELF binaries.

7.5k|1.8k|Updated Nov 10, 2013
One-click install
npx skills add https://github.com/FastLED/FastLED --skill embedded-debug
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: embedded-debug
Source: https://github.com/FastLED/FastLED/tree/main/.claude/skills/embedded-debug
Command: npx skills add https://github.com/FastLED/FastLED --skill embedded-debug

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Diagnosing firmware crashes on embedded devices can be time-consuming. This skill parses crash outputs, decodes stack traces, and interprets register dumps to accelerate fault localization and remediation.

Core Features & Use Cases

  • Crash Analysis: Parse panic handlers, guru meditation errors, hard faults, watchdog resets, and collect diagnostic context from logs.
  • Stack Trace Decoding: Map raw addresses to function names using ELF binaries and build IDs to pinpoint exact code paths.
  • Register Dump Interpretation: Translate CPU register states into meaningful insights to identify faulty instructions or memory corruption.
  • Root Cause Identification & Fixes: Correlate crash data with source code and offer concrete remediation steps to prevent reoccurrence.
  • Use Case: Diagnose intermittent ESP32 panics in field deployments and guide firmware fixes in a reproducible workflow.

Quick Start

Provide the crash output or a description of the issue to start analyzing the fault.

Frequently Asked Questions about embedded-debug

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decode an ESP32 guru meditation error from a crash log?

To decode an ESP32 guru meditation error, you need the crash output and the corresponding ELF binary. This skill parses the panic handler logs, maps raw stack trace addresses to function names using the ELF file, and identifies the exact faulty code path.

What do I need to decode stack traces for ARM Cortex-M hard faults?

Decoding ARM Cortex-M hard faults requires the raw crash output, a CPU register dump, and the compiled ELF binary. The skill translates the register states and maps stack addresses against the ELF to pinpoint the faulty instructions causing the hard fault.

Can I analyze a core dump to find the root cause of a firmware panic?

Yes, you can analyze a core dump to find the root cause of a firmware panic. By correlating the crash data and register dump with the source code via the ELF binary, the skill provides concrete remediation steps to prevent reoccurrence.

Does decoding embedded crashes work with AVR platforms and watchdog resets?

Yes, decoding embedded crashes works with AVR platforms, ESP32, and ARM Cortex-M devices. The skill handles watchdog resets and hard faults by interpreting CPU register dumps to identify memory corruption or faulty instructions.

Why do I need an ELF binary to analyze a firmware stack trace?

An ELF binary is required to analyze a firmware stack trace because it contains the build IDs and debug symbols needed for address mapping. The skill uses the ELF to translate raw memory addresses from the crash dump into exact function names.

What's the best way to diagnose intermittent ESP32 panics in field deployments?

The best way to diagnose intermittent ESP32 panics is to capture the crash output and register dump from the field device, then use this skill to correlate the stack trace with your source code. It provides a reproducible workflow to guide firmware fixes.