Skill routes
TTDD = DDTT + other witnesses of the target. The module covers checks with stops; companion skills add views without halting the core, from outside and without a board.
Target witnesses
| Witness | What it shows | Effect on the target | Skills |
|---|---|---|---|
| GDB and SWD with stops (DDTT) | state at a stop point: variables, registers, MMIO, returns; injected data and faults | the core halts at breakpoints | scenarios, run |
| SWD without halting the core | variables and registers over time while the firmware runs | bus memory reads only | stm32-diag-record, stm32-ros-alt-channel |
| The firmware's own output | log, telemetry and events published by the firmware itself | needs a channel in the firmware | stm32-rtt-console, stm32-swo-trace, stm32-ros-alt-channel |
| MCU pins from outside | real time: edges, PWM, ISR jitter, buses on the wire | none, a passive probe | weact-logic-analyzer |
| A model without a board | ELF execution on a model, peripheral accesses | none; preparation, not a test on target | renode, stm32-renode-emulator |
| Requirements | what to check: requirement and test case IDs, tolerances | — | embedded-tech-spec |
Rules
The requirement judgesThe expectation comes from the requirement; each witness only confirms or refutes it. Disagreeing witnesses are a finding.
Stops change timingMeasure time, frequency and jitter with a witness that leaves the core running; keep DDTT for configuration, branches and faults.
One SWD ownerNever start two GDB servers on one probe; an analyzer and UART may run in parallel.
Evidence togetherRecords of one experiment share the scenario or requirement ID and sit next to result.json.
An emulator preparesA model saves board attempts, but only the board supports "verified on target".
Choosing a skill
| Skill | When and what to supply | Result |
|---|---|---|
integrate | First integration or version upgrade. Supply the CMake project and desired tag; verify configuration and prepare before one hardware scenario. | Pinned gitlink, HIL configuration, presets and a reproducible run command. |
scenarios | A firmware requirement is already defined. Specify observable behaviour and allowed interventions; derive expectations from the requirement, not the current board response. | Scenario and ELF contract; logical-time for thresholds/retry, counter-cost for deltas/cost. external-capture is a separate host fixture, not @case. |
run | Execute a specific attempt. Supply a session or package and stand; start with doctor and prepare. Code changes belong in develop, not unexplained retries. | Command and scenario outcomes, logs, recovery and an explanation of FAIL/ERROR/SKIP. |
results | Evidence already exists. Supply the complete attempt or campaign and matching sources; check provenance and integrity before interpreting records. | Separate scenario, capture, analysis and cleanup outcomes. neutral-workflows links three examples to criteria; UNKNOWN is not zero and campaign PASS preserves intended FAILs. |
stand-loop | Repeat an accepted immutable bundle. Define finite cycles, FAIL/SKIP policy and STOP; rebuild the bundle when the ELF or scenario changes. | Separate attempts, cycle summary and review.json handoff; application sources are not required on the stand. |
develop | Change firmware with feedback from the circuit. Supply requirements, sources, stand description and an iteration budget; retain the plan and baseline FAIL before fixing. | Requirement → baseline defect → fix → same scenario and repeat. Do not hide retries with reset or fit clock anchors to desired results. |
hse-qualify | Supply nominal frequency, tolerance, board and allowed operations; establish clock accuracy before hardware measurement. | Frequency interval, IN_TOLERANCE/OUT_OF_TOLERANCE/UNKNOWN, separate recovery verdict and epoch scope. |
Typical routes
no board: requirements, scenariossetup, emulatorboard accessresult review
New project
Requirements and test cases → module integration → scenarios → run → review.
Firmware change
develop uses scenarios, run and results at each step: the baseline FAIL is recorded before the fix, the regression after it.
Timing requirement
MMIO and SVD check the peripheral setup, the analyzer measures the pin without halting the core, results relates both witnesses. Crystal frequency is the separate hse-qualify route.
Behaviour in operation
A DDTT scenario brings the board to a state and checks transitions, an SWD or ROS1 recording keeps the stream next to result.json under the same ID.
No board → board
A short experiment and the model limits in Renode or QEMU, then the same scenario on the stand.
Diagnostic channel
RTT or SWO show what the firmware does between stops; they do not replace a DDTT scenario but help explain a FAIL.
Autonomous stand
Finite cycles of an immutable bundle and attempt review; a discovered issue becomes a separate develop cycle.
Module skills
Each skill is a directory with SKILL.md in the Agent Skills format; the skill version matches the module.
Companion skills
From demo-stm32-skills: requirements, emulators, observation without halting the core, signals on pins.