Skip to main content
Use xSCOPE for output from an XMOS .xe application on hardware or in the simulator. Add a Serial tab to the Monitor and select the XMOS target and artifact.

Prepare the target

Install XMOS XTC Tools for the hardware host and build the .xe with xSCOPE support. For hardware, connect and power the board and its xTAG. For a simulated run, choose the simulator explicitly. Set the artifact and target in .embedder/xmos.json. Merge these fields into the file if it already exists:
.embedder/xmos.json
Replace build/my_app.xe with the artifact’s path relative to the project root. If several xTAGs are attached, select the intended adapter or add its ID as "adapterId" in the same file. Use "target": "simulator" only for a simulated run. XMOS settings such as xmos_xe in EMBEDDER.md are no longer used.

Start a monitored run

A fresh xSCOPE Monitor connection launches the selected .xe on the chosen xTAG or simulator. An existing matching debugger console can be reused; the Monitor reports Attached to xgdbserver console when that happens. To preserve a running target or fault, verify reuse of the existing console or read already captured history before starting a new connection.
Confirm the selected artifact, hardware or simulator target, and expected startup output before interpreting the result. Simulator output is evidence about that simulated run, not the connected board.

Reconnect after agent commands

Embedder disconnects the Monitor’s xSCOPE connections before it runs any agent shell command. It does the same before flash, debugger server, and hardware script tools. The Monitor tab shows xSCOPE monitoring stopped. Reconnect explicitly after the command finishes. Output already captured stays in the Monitor history. On hardware, the program keeps running without being observed. A simulated run stops. The Monitor can’t reconnect until the command finishes and its cleanup completes. This includes background shell commands and any processes they leave running. Embedder doesn’t reconnect the Monitor automatically, so reconnect it yourself when the command is done. The one exception is a flash that captures boot output. In that case, the Monitor joins the capture session once the hardware commands finish. Reconnecting starts a new session that loads the last image Embedder ran on that target again. If you rebuild the .xe at the same path, the new session runs the new build. If you changed xe in .embedder/xmos.json since that load, the new session runs the configured .xe instead.
Trace recordings and capture sessions that share the xSCOPE connection stay connected during these commands. See XMOS debugging for debugger setup and .xe execution controls.

Record probes and prints in Trace

An xSCOPE event recording captures values from the firmware’s registered probes and its xSCOPE prints. Use the matching .xe, select hardware or simulator explicitly, and enable realtime xSCOPE with "xscope": true before preparing a shared Monitor connection.
A compatible active Monitor or debugger session can be shared. A fresh recording can launch the application, just like a fresh Monitor connection. A stdout-only session must be prepared for realtime recording before it can supply these events; preserve existing fault evidence before restarting it. After reproduction, ask Embedder to stop the recording. In Trace, registered numeric probe values appear as counters and prints as events. Check the expected probe names and any dropped-record warnings before interpreting the timeline. You can query the saved recording without launching the application again. For instruction execution rather than application probes, see XMOS xsim and Coverage and trace.

Send supported input

Add "xscope": true to .embedder/xmos.json and connect the Monitor in realtime xSCOPE mode. The firmware must be built with xSCOPE enabled and receive input through xscope_data_from_host. Enter a command the firmware recognizes in the Monitor’s send control, using the newline convention it expects. Check the firmware response afterward. Stdout-only monitoring cannot send input. Changing from an existing stdout-only session may require disconnecting and starting a new connection, which can launch the selected application again. Baud rate, DTR, and RTS settings do not apply to xSCOPE. When Embedder monitors an xscope:// port, it also ignores UART, RTT, and ITM settings such as baud rate, frequency, CPU frequency, device, and interface.

Read an existing run

Use history for output already captured, and a live request with a duration or stop string for future output.

Troubleshoot

  • xrun missing: install XTC Tools, launch Embedder from its tools environment, or set EMBEDDER_XTC_PATH to the XTC installation.
  • Artifact missing or wrong: rebuild, check xe in .embedder/xmos.json, and confirm the Monitor’s selected application.
  • Several xTAGs found: select the intended adapter ID explicitly.
  • Probe busy: finish the competing hardware task, or use the matching existing debugger console where available.
  • Monitor shows xSCOPE monitoring stopped: an agent command suspended the connection. Wait for the command and its cleanup to finish, then reconnect the Monitor.
  • Input unavailable: check "xscope": true, the active realtime connection, and the firmware’s xscope_data_from_host receiver.
  • No output: confirm the selected build enables xSCOPE and reaches its logging code.
Last modified on September 12, 2026