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
Added on

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

  1. First read references/usage.md to confirm whether this is environment detection, configuration scanning, or flashing execution.
  2. If unsure about the probe status, first run the
    --detect
    mode of the built-in script scripts/openocd_flasher.py to confirm.
  3. If unsure about the OpenOCD configuration, use
    --scan-configs
    to scan workspace clues.
  4. Use
    --artifact
    to specify the artifact, and execute flashing with
    --interface
    +
    --target
    or
    --config
    .
  5. For BIN files,
    --base-address
    must be provided at the same time.
  6. Read the flashing result report output by the script, focusing on verification status and failure categories.
  7. 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
    .