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.
3installs
Sourceleokemp223/embed-ai-tool
Added on
NPX Install
npx skill4agent add leokemp223/embed-ai-tool flash-openocdTags
Translated version includes tags in frontmatterSKILL.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 Profilescanned workspace clues.--scan-configs - If the artifact is , a clear flashing base address must be obtained from the workspace or user input; otherwise, the script will block.
BIN - 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 mode of the built-in script scripts/openocd_flasher.py to confirm.
--detect - If unsure about the OpenOCD configuration, use to scan workspace clues.
--scan-configs - Use to specify the artifact, and execute flashing with
--artifact+--interfaceor--target.--config - For BIN files, must be provided at the same time.
--base-address - Read the flashing result report output by the script, focusing on verification status and failure categories.
- Write the flashing configuration and results back to , and hand over to downstream skill when needed.
Project Profile
Failure Diversion
- When is unavailable, return
openocd.environment-missing - When the artifact cannot be safely parsed, or lacks the flashing base address, return
BIN.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_kindin theopenocd_config.Project Profile - Recommend the next skill based on user intent: recommend after startup verification, and recommend
serial-monitorwhen debugging is needed.debug-gdb-openocd
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