SuperAPI AI Directory

flash-openocd

Coding & development

View repository

Updated 10-15 23:58

About this skill

OpenOCD Flashing

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_path containing Project 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.json as default parameters (explicit parameters take precedence; no need to manually pass --resume);--resume is 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-configs workspace 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

  1. First read references/usage.mdto confirm whether this is environment detection, configuration scanning, or performing a flash.
  2. If unsure about the probe status, first run the bundled script scripts/openocd_flasher.py 's --detect mode to confirm.
  3. If unsure about the OpenOCD configuration, use --scan-configs to scan the workspace for clues.
  4. Use --artifact to specify the artifact, together with --interface + --target or --config to perform the flash.
  5. For BIN files, --base-address。
  6. must also be provided. Read the flash result report output by the script, focusing on the verification status and failure classification.
  7. Write the flash configuration and results back to Project Profile, and hand off to downstream skills when needed.

Failure Triage

  • When openocd is unavailable, return environment-missing。
  • When the artifact cannot be safely resolved, or BIN lacks a flash base address, return artifact-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 Profile retain or update artifact_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, recommend debug-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。