flash-jlink

J-Link Flashing

Applicable Scenarios

A usable firmware artifact already exists in the workspace, and the target board is connected to a SEGGER J-Link probe.
You need to use J-Link Commander for flashing and verification, rather than OpenOCD.
You need to use J-Link RTT (Real-Time Transfer) for high-speed log capture.
You need to scan the workspace for .jlink configuration files or J-Link settings in .vscode/launch.json .

The firmware artifact path, or the artifact_path containing Project Profile。
--device parameter specifies the target chip model (e.g., STM32F407VG), which J-Link Commander requires to be specified.
Optional interface type (SWD or JTAG, default SWD) and flashing speed.
If the artifact is a BIN, the --base-address flashing base address is also required.

Upon startup, the script automatically reuses the last successful profile in the project root directory .em_skill.json as the default parameters (explicit parameters take precedence; no need to manually pass --resume）；--resume is only used to assert that the cache must exist; exits non-zero if there is no cache. 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 automatically locates JLinkExe, searching in the order of configuration files, PATH, and common installation paths.
--scan-configs Scan the workspace for .jlink files and the J-Link configuration in .vscode/launch.json .
It will not guess the device name; when --device is missing, it blocks and returns ambiguous-context。

First read references/usage.mdto confirm whether this is environment detection, configuration scanning, or performing a flash.
If you are unsure about the J-Link environment status, first run the built-in script scripts/jlink_flasher.py 's --detect mode to confirm.
If you are unsure about the device model or interface configuration, use --scan-configs to scan the workspace for clues.
Use --artifact + --device to perform the flash, optionally --interface and --speed。
For BIN files, you must also provide --base-address。
When RTT logs are needed, use --rtt to start RTT capture.
Read the flashing result report output by the script, focusing on the verification status and failure classification.

When JLinkExe is unavailable, return environment-missing。
When the artifact cannot be safely resolved, or BIN lacks a flashing base address, return artifact-missing。
When J-Link cannot discover the probe or target, return connection-failure。
When the configuration file is invalid or the device name is not recognized by J-Link, return project-config-error。
When flashing starts but verification or reset fails, return target-response-abnormal。
When --device is missing and cannot be inferred from the workspace, return ambiguous-context。

JLinkExe is JLinkExeon Linux/macOS, and JLink.exe。
SEGGER default installation paths: Linux /opt/SEGGER/JLink/，Windows C:\Program Files\SEGGER\JLink\。
The built-in script uses the Python standard library and subprocess to call JLinkExe, and is cross-platform compatible.
RTT functionality is unique to J-Link, does not occupy a UART, and is suitable for scenarios without a serial port.

Output the JLinkExe command, device name, interface type, artifact path, and verification result.
In Project Profile keep or update artifact_path、artifact_kind、jlink_device、jlink_interface。
After successful flashing, it is recommended to serial-monitor or debug-jlink。

When the next step is to check runtime logs, hand off the successful flashing result to serial-monitor。
When the user needs GDB debugging, hand off the result to debug-jlink。
When RTT logs are needed instead of serial, you can directly use this skill's --rtt mode.