Applicable Scenarios
- The workspace already has usable firmware artifacts, and the user wants to flash the program to the hardware.
- The detected or user-specified probe is compatible with OpenOCD.
- The team needs a standardized OpenOCD flashing process that can smoothly hand off to serial observation or debugging.
- The probe connection status needs to be confirmed before flashing, or OpenOCD configuration clues in the workspace need to be scanned.
Required Inputs
- Firmware artifact path, or a
artifact_pathcontainingProject Profile。 - OpenOCD configuration information: explicit interface + target configuration, board-level configuration, existing profile data, or configuration clues in the workspace.
- Optional reset behavior and verification preference. Verification and reset are enabled by default.
- If the artifact is a BIN, the flash base address is also required.
Automatic Detection
- On startup, the script automatically reuses the last successful profile in the project root directory
.em_skill.jsonas default parameters (explicit parameters take precedence; no need to manually pass--resume);--resumeis only used to assert that the cache must exist; if there is no cache, it exits with a non-zero code. When there is no cache or the user explicitly requests re-detection, the script automatically falls back to a normal scan. - Select the firmware artifact by
ELF > HEX > BIN. - The script can automatically detect connected debug probes (ST-Link, CMSIS-DAP, J-Link), preferring the first one detected.
- Configuration priority is, in order: explicit user input, existing
Project Profile、--scan-configsworkspace clues found by scanning. - If the artifact is
BIN, an explicit flash base address must be obtained from the workspace or user input; otherwise the script will block. - Do not concatenate multiple "partial match" configurations; in this case, return
ambiguous-context。
Execution Steps
- First read references/usage.mdto confirm whether this is environment detection, configuration scanning, or performing a flash.
- If unsure about the probe status, first run the bundled script scripts/openocd_flasher.py 's
--detectmode to confirm. - If unsure about the OpenOCD configuration, use
--scan-configsto scan the workspace for clues. - Use
--artifactto specify the artifact, together with--interface+--targetor--configto perform the flash. - For BIN files,
--base-address。 - must also be provided. Read the flash result report output by the script, focusing on the verification status and failure classification.
- Write the flash configuration and results back to
Project Profile, and hand off to downstream skills when needed.
Failure Triage
- When
openocdis unavailable, returnenvironment-missing。 - When the artifact cannot be safely resolved, or
BINlacks a flash base address, returnartifact-missing。 - When OpenOCD cannot discover the probe or target board, return
connection-failure。 - When the selected configuration file is invalid, return
project-config-error。 - When flashing has started but verification, core halt, or reset fails, return
target-response-abnormal。 - When there are multiple equally reasonable configuration sets or targets, return
ambiguous-context。
Platform Notes
- Probe access failures can manifest as USB or driver issues on all host platforms; only the specific error text varies by operating system.
- The bundled script uses the Python standard library and subprocess to call openocd, so the flashing scheduling path itself is cross-platform.
- The full OpenOCD configuration list should be retained in the output to make it easy to reproduce the same session in other host environments.
Output conventions
- Output the OpenOCD command, the selected configuration files, the artifact path, and whether verification and reset are required.
- In
Project Profileretain or updateartifact_path、artifact_kind、openocd_config。 - Recommend the next skill based on user intent: after doing boot verification, recommend
serial-monitor, and when debugging is needed, recommenddebug-gdb-openocd。
Handoff relationships
- When the next step is to review runtime logs, hand off the successful flashing result to
serial-monitor。 - When the user needs breakpoints, core halt control, or crash analysis, hand off the successful or partially successful flashing result to
debug-gdb-openocd。