Skip to main content
Ask Embedder to flash from Act or Debug mode after a successful build. Identify the target, artifact, and programming method before starting. Flashing can erase or replace firmware, reset the target, and interrupt an existing debugger session.

​
Prepare the project

  1. Connect and power the intended board and probe.
  2. Build firmware for the exact MCU and board revision.
  3. Confirm the artifact path and the project’s flash command in EMBEDDER.md.
  4. Install the toolchain and programming utility on the machine connected to the board.
  5. Identify the boot-output transport and, for UART, the port and baud rate.
Use the project’s established PlatformIO, ESP-IDF, Zephyr, or vendor command. Embedder can run that command; it still needs the utility, board configuration, drivers, and access permissions required by the project.

​
Flash a local board

Adjust the baud rate, duration, and expected message to your firmware. Providing the UART settings before flashing lets Embedder try to subscribe before the command runs. If the port disappears or cannot be opened early, capture may start after programming; an empty log does not prove the firmware failed to boot. The ordinary flash-command timeout is five minutes. Request more time if the project’s programming process needs it. The command’s own reset behavior determines when the application starts; verify the observed result. For SWO output, flash first and then follow ITM/SWO. An ITM port cannot be used as the flash command’s serial-capture port.

​
Flash through a bridge

Select the hardware bridge in the conversation, identify its target, and provide the built artifact:
For a target with a known MCU, Embedder uses probe-rs. When no MCU name is configured, a target with an OpenOCD target and compatible debug interface can use OpenOCD. This bridge workflow requires a selected bridge; ordinary local flashing uses the project’s flash command. XMOS .xe handling is described below. Remote flashing is followed by a separate monitoring request. Keep programming success and boot verification as separate checks.

​
Program XMOS hardware

Use XMOS xTAG and xgdb for .xe artifacts and XTC Tools setup. Flash programming uses xflash. Starting an xSCOPE capture afterward can run the image from RAM, so use the power-cycle check in that guide to verify boot from flash. xsim reloads the simulator instead of programming a physical board.

​
Prepare an AURIX project

For the supported Windows ADS/iLLD workflow, follow AURIX ADS and Flasher. Project setup creates command-line build files; programming is a separate step using AURIX Flasher and the generated HEX artifact.

​
Troubleshoot

  • Wrong or missing artifact: rebuild for the selected board and use the actual output path.
  • Probe busy: stop conflicting captures or debugger connections; check /hardware-queue for another session’s use.
  • Programming succeeds but READY is absent: verify the output transport, baud rate, capture start time, and reset result.
  • Board is no longer detected: check power, cable, boot mode, and the board’s recovery instructions before retrying.
To observe an existing failure without replacing firmware, start with Monitor and debug.
Last modified on September 12, 2026