flash-openocd

Original：🇨🇳 Chinese

Translated

1 scriptsChecked / no sensitive code detected

Used when you need to call the built-in script to flash embedded firmware via OpenOCD using detected or explicitly specified artifact and probe configurations.

4installs

Sourceleokemp223/embed-ai-tool

Added on2026-05-16

NPX Install

npx skill4agent add leokemp223/embed-ai-tool flash-openocd

SKILL.md Content (Chinese)

View Translation Comparison →

OpenOCD Flashing

Applicable Scenarios

The workspace already has available 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 transition to serial observation or debugging.
Need to confirm probe connection status or scan OpenOCD configuration clues in the workspace before flashing.

Required Inputs

Firmware artifact path, or a Project Profile containing
```
artifact_path
```
.
OpenOCD configuration information: explicit interface + target configuration, board-level configuration, existing profile data, or configuration clues in the workspace.
Optional reset behavior and verification preferences. Verification and reset are enabled by default.
If the artifact is BIN, the flashing base address is also required.

Auto-detection

Select firmware artifacts in the order of
```
ELF > HEX > BIN
```
.
The script can automatically detect connected debug probes (ST-Link, CMSIS-DAP, J-Link), prioritizing the first one detected.
Configuration priority is as follows: explicit user input, existing
```
Project Profile
```
,
```
--scan-configs
```
scanned workspace clues.
If the artifact is
```
BIN
```
, a clear flashing base address must be obtained from the workspace or user input; otherwise, the script will block.
Do not splice multiple "partially matched" configurations; in such cases, return
```
ambiguous-context
```
.

Execution Steps

First read references/usage.md to confirm whether this is environment detection, configuration scanning, or flashing execution.
If unsure about the probe status, first run the
```
--detect
```
mode of the built-in script scripts/openocd_flasher.py to confirm.
If unsure about the OpenOCD configuration, use
```
--scan-configs
```
to scan workspace clues.
Use
```
--artifact
```
to specify the artifact, and execute flashing with
```
--interface
```
+
```
--target
```
or
```
--config
```
.
For BIN files,
```
--base-address
```
must be provided at the same time.
Read the flashing result report output by the script, focusing on verification status and failure categories.
Write the flashing configuration and results back to
```
Project Profile
```
, and hand over to downstream skill when needed.

Failure Diversion

When
```
openocd
```
is unavailable, return
```
environment-missing
```
.
When the artifact cannot be safely parsed, or
```
BIN
```
lacks the flashing base address, return
```
artifact-missing
```
.
When OpenOCD cannot detect the probe or target board, return
```
connection-failure
```
.
When the selected configuration file is invalid, return
```
project-config-error
```
.
When flashing starts but verification, core halt, or reset fails, return
```
target-response-abnormal
```
.
When multiple equally reasonable configuration sets or targets exist, return
```
ambiguous-context
```
.

Platform Notes

Probe access failures may manifest as USB or driver issues on all host platforms, although specific error messages vary by operating system.
The built-in script uses Python standard libraries and subprocess to call openocd, so the flashing scheduling path itself is cross-platform.
The complete list of OpenOCD configurations should be retained in the output to facilitate reproducing the same session in other host environments.

Output Conventions

Output the OpenOCD command, selected configuration files, artifact path, and whether verification and reset are required.

Retain or update

artifact_path

,

artifact_kind

,

openocd_config

in the

Project Profile

.

Recommend the next skill based on user intent: recommend
```
serial-monitor
```
after startup verification, and recommend
```
debug-gdb-openocd
```
when debugging is needed.

Handover Relationships

When the next step is to view running logs, hand over the successful flashing result to
```
serial-monitor
```
.
When the user needs breakpoints, core halt control, or crash analysis, hand over the successful or partially successful flashing result to
```
debug-gdb-openocd
```
.