embedded-verification

Name: embedded-verification
Availability: InStock
Author: Emin

Verifies embedded firmware through build-flash-monitor loops before allowing completion claims.

Updated Sep 3, 2024

Search Tags:#testing #verification #firmware #embedded #esp-idf #serial monitor #build flash monitor

Ready to run

npx skills add https://github.com/eminboydak/duckTerm --skill embedded-verification-eminboydak

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: embedded-verification
Source: https://github.com/eminboydak/duckTerm/tree/main/.agents/skills/embedded-dev/skills/embedded-verification
Command: npx skills add https://github.com/eminboydak/duckTerm --skill embedded-verification-eminboydak

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Embedded developers often claim firmware works based on a successful build alone, only to discover crashes or wrong behavior on hardware later. This Skill enforces an evidence-first verification gate so no completion claim is made without fresh build, flash, and monitor output. ## Core Features & Use Cases - Build-Flash-Monitor Loop: Runs the full idf.py build, flash, and monitor sequence and checks exit codes, errors, and runtime logs. - Verification Report: Produces a structured report covering build status, flash status, monitor duration, crashes, and runtime feature checks. - Red Flag Detection: Blocks claims like "should work now" or "build passed earlier" and forces fresh verification runs. - Use Case: After implementing an ESP32 display driver, run this Skill to build, flash to COM3, monitor serial output for 30+ seconds, and confirm initialization logs before declaring the driver complete. ## Quick Start Verify my ESP32 firmware by running the full build-flash-monitor loop and report whether it passes.

Frequently Asked Questions about embedded-verification

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

FAQPage Schema

How do I verify ESP32 firmware after building with idf.py?▼

Run the full loop: idf.py build, then idf.py -p PORT flash, then idf.py monitor for at least 30 seconds. Check exit codes, confirm flash success, and inspect monitor output for crashes or missing initialization logs before claiming completion.

What is the build-flash-monitor loop in embedded development?▼

It is a verification sequence that compiles firmware, flashes it to the target device, and monitors serial output at runtime. Passing all three stages provides evidence the firmware actually works on hardware, not just that it compiles.

Why is a successful build not enough to claim firmware works?▼

A successful build only proves the code compiles. Runtime issues like Guru Meditation errors, assertion failures, wrong sensor readings, or failed Wi-Fi connections only appear during flash and monitor phases on real hardware.

How do I flash and monitor ESP32 firmware on Windows?▼

In PowerShell run idf.py -p COM3 flash, then idf.py monitor, replacing COM3 with your actual port. Check $LASTEXITCODE after each command to confirm success before proceeding to the next stage.

When should embedded verification run in the development workflow?▼

Run it after implementation completes all tasks and before any GUI feedback or completion claims. If any stage fails, fix the issue and re-run the full loop rather than proceeding with partial evidence.