Debug - Lager

Control debugger operations for embedded development including flashing, GDB server management, memory access, and RTT logging.

Syntax

lager debug [OPTIONS] [NET_NAME] COMMAND [ARGS]...

Global Options

Option	Description
`--box TEXT`	Lager Box name or IP address
`--help`	Show help message and exit

Commands

Command	Description
`gdbserver`	Start the GDB server (JLinkGDBServer or OpenOCD) for debugging
`disconnect`	Stop the GDB server
`flash`	Flash firmware to target
`reset`	Reset target device
`erase`	Erase flash memory (all of it or a given range; 1 MiB on DA1469x by default)
`memrd`	Read memory from target
`status`	Show debug net status
`health`	Check debug service health

Command Reference

`gdbserver`

Start the GDB server for remote debugging. This is the primary command to establish a debug connection. The box selects the backend from the probe. A J-Link probe uses JLinkGDBServer. Other supported probes use OpenOCD. See Supported Debug Probes.

lager debug [NET_NAME] gdbserver [OPTIONS]

Options:

--box TEXT - Lager Box name or IP
--force / --no-force - Force new connection (default: reuse existing)
--halt / --no-halt - Halt device when connecting (default: no-halt)
--speed KHZ - SWD/JTAG speed in kHz (e.g., 100, 4000) or “adaptive”
--quiet - Suppress informational messages
--json - Output results in JSON format
--rtt - Automatically stream RTT logs after starting GDB server
--rtt-reset - Reset device then stream RTT (captures boot sequence)
-i, --interactive - Bi-directional RTT: forward stdin to the target’s RTT down-channel while streaming the up-channel to stdout (requires --rtt or --rtt-reset)
--rtt-channel N - RTT channel to stream, in both directions (default: 0)
--reset - Reset device after starting GDB server
--gdb-port PORT - Override the auto-allocated GDB server port. By default the box picks a port from the probe’s slot (2331 for the first probe, 2334 for the second). Pass this only when you need a specific port. Avoid it on multi-probe boxes.
--rtt-search-addr HEX - RAM start address for the RTT control block search (hex, e.g., 0x20020000)
--rtt-search-size HEX - Size of the RAM region to search for the RTT control block (hex, e.g., 0x4000)
--rtt-chunk-size HEX - Read chunk size for the RTT search (hex, e.g., 0x1000)
--local-port PORT - Local port for the tunnel on a box behind a gateway (default: the same port as the GDB server on the box)
--no-tunnel - On a box behind a gateway, start the GDB server and return without a tunnel to it

Examples:

# Start GDB server on default debug net
lager debug gdbserver --box my-lager-box

# Start GDB server on specific net with halt
lager debug debug1 gdbserver --box my-lager-box --halt

# Start GDB server and stream RTT logs
lager debug gdbserver --box my-lager-box --rtt

# Capture boot sequence via RTT
lager debug gdbserver --box my-lager-box --rtt-reset

# Send commands to the target while reading its RTT output
lager debug gdbserver --box my-lager-box --rtt --interactive

# Use custom speed and port
lager debug gdbserver --box my-lager-box --speed 4000 --gdb-port 3333

Connecting with GDB:

# After starting gdbserver, connect with:
arm-none-eabi-gdb firmware.elf -ex 'target remote <BOX_IP>:2331'

The command prints the exact address to use. On a plain Lager Box, it prints the address of the box and returns. Boxes behind a gateway: Some boxes are behind an authenticating gateway (see lager login). The gateway checks your sign-in on each connection. The GDB port of such a box is not open to the network, so GDB cannot connect to the box directly. On such a box, gdbserver starts the GDB server and then opens a tunnel through the gateway. The tunnel listens on localhost only, on the same port number as the GDB server on the box. The command stays in the foreground while the tunnel is open:

JLinkGDBServer started!
GDB server running on my-lager-box. Connect to localhost:2331
Connect with: arm-none-eabi-gdb -ex 'target remote localhost:2331'
Tunnelling through the box's gateway. Press Ctrl-C to close the tunnel.

# In a second terminal
arm-none-eabi-gdb firmware.elf -ex 'target remote localhost:2331'

The command decides for each box whether a tunnel is necessary. You do not set an option for it.
GDB can disconnect and connect again while the tunnel is open. More than one client can connect at the same time.
Ctrl-C closes the tunnel only. The GDB server continues to run on the box. To stop it, use lager debug <NET> disconnect.
If the local port is in use, the command stops with an error. Use --local-port to select a different local port.
With --rtt, --rtt-reset or --interactive, the tunnel stays open while the RTT stream runs. RTT does not use the tunnel: it goes through the gateway as normal HTTP.
With --json, the output has a tunnel object with local_host and local_port. Then the command stays in the foreground.
A script that must continue after the GDB server starts can use --no-tunnel. The command then returns and does not open a tunnel.
If an administrator removes your access to the box, the gateway closes the tunnel within about one minute. The command tells you. The next connection gets the access error.

If the gateway of the box does not support debug tunnels yet, the command still starts the GDB server and exits successfully. It warns that no debugger on this machine can reach the server, and prints no address to connect to. The gateway must be updated before you can attach a debugger. Speak to the administrator of the box.

`disconnect`

Stop the GDB server (JLinkGDBServer or OpenOCD) and free debug resources.

lager debug [NET_NAME] disconnect [OPTIONS]

Options:

--box TEXT - Lager Box name or IP
--keep-server - Keep the GDB server running for external connections

Examples:

# Stop GDB server completely
lager debug disconnect --box my-lager-box

# Disconnect but keep server running
lager debug disconnect --box my-lager-box --keep-server

`flash`

Flash firmware to target. Supports Intel HEX, ELF, and binary file formats.

lager debug [NET_NAME] flash [OPTIONS]

Options:

--box TEXT - Lager Box name or IP
--hex FILE - Path to Intel HEX file
--elf FILE - Path to ELF executable
--bin FILE,ADDRESS - Path to a binary file and its load address, as one argument (for example build/app.bin,0x08000000)
--verbose - Show detailed J-Link output
--force-reconnect - Force clean reconnect before flash
--no-erase - Skip the erase step (by default flash erases before programming for a clean state)
--erase-start ADDR - First address of the erase before programming, hex (0x16000000) or decimal. Given together with --erase-size.
--erase-size BYTES - Bytes to erase from --erase-start: decimal, 0x hex, or a K/M suffix such as 2M.
--halt / --no-halt - Halt device after flashing (default: no-halt)

flash erases before programming by default, so no flag is needed for a clean state (this is what RTT initialization wants). Pass --no-erase only when you intentionally want to preserve existing flash contents. The older --erase flag is now a no-op kept for backward compatibility.

--erase-start and --erase-size set the range of that erase, on both backends. Without them, flash erases the whole chip, or 1 MiB from 0x16000000 on a DA1469x. The erase section below describes the range, and the box version it needs. Failure output:

If the erase before programming fails, flash prints Flash erase failed: and the error, then exits 1. It does not program the target.
If programming fails, flash prints Flash failed: and the failing line, then The target was NOT programmed. If this ran without --no-erase it is now erased. It exits 1.
On J-Link, the output of the probe decides. These lines fail the command: a connect failure, a probe that another client holds, and a failed RAMCode download. Examples are Selected interface (SWD) is not supported by the connected probe. and Failed to download RAMCode!. The erase section below lists the connect-failure lines. Success also needs J-Link’s own evidence: a J-Link: Flash download: line (or O.K.) after Downloading file. A flash without it did not program the target, and it fails.
A failed J-Link flash adds Diagnosis: lines. They name any other J-Link program that used the probe during the flash. On a DA1469x, they also tell if the target reset during programming.
If your target’s J-Link output does not contain these evidence lines, set LAGER_JLINK_REQUIRE_EVIDENCE=0 in the environment of the CLI. The CLI then does not require them for flash and erase. Failure lines still fail the command.

Examples:

# Flash Intel HEX file
lager debug flash --hex build/firmware.hex --box my-lager-box

# Flash ELF file
lager debug flash --elf build/firmware.elf --box my-lager-box

# Flash binary with base address
lager debug flash --bin build/firmware.bin,0x08000000 --box my-lager-box

# Flash while preserving existing flash contents (skip the default erase)
lager debug flash --hex build/firmware.hex --no-erase --box my-lager-box

# Erase 2 MiB from the start of QSPI on a DA1469x, then flash
lager debug flash --bin build/app.bin,0x16000000 --erase-start 0x16000000 --erase-size 2M --box my-lager-box

# Flash and halt for debugging
lager debug flash --elf build/firmware.elf --halt --box my-lager-box

# Verbose output for troubleshooting
lager debug flash --hex build/firmware.hex --verbose --box my-lager-box

`reset`

Reset the target device.

lager debug [NET_NAME] reset [OPTIONS]

Options:

--box TEXT - Lager Box name or IP
--halt / --no-halt - Halt after reset (default: no-halt)
--force-reconnect - Force clean reconnect before reset

Examples:

# Reset and run
lager debug reset --box my-lager-box

# Reset and halt (for debugging)
lager debug reset --halt --box my-lager-box

# Force clean state before reset
lager debug reset --force-reconnect --box my-lager-box

`erase`

Erase flash memory on the target: all of it, or the range you give with --erase-start and --erase-size. This is a destructive operation. On a DA1469x, erase erases only a range of the external QSPI flash. See DA1469x Targets.

lager debug [NET_NAME] erase [OPTIONS]

Options:

--box TEXT - Lager Box name or IP
--speed KHZ - SWD/JTAG speed in kHz (default: 4000)
--yes - Skip confirmation prompt
--quiet - Suppress warning messages. This also skips the confirmation prompt.
--json - Output results in JSON format. This also skips the confirmation prompt.
--erase-start ADDR - First address to erase, hex (0x16000000) or decimal. Given together with --erase-size.
--erase-size BYTES - Bytes to erase from --erase-start: decimal, 0x hex, or a K/M suffix such as 2M.
--halt / --no-halt - Halt after erase (default: no-halt)

Erase range: --erase-start and --erase-size are given together. --erase-start takes hex (0x16000000) or decimal. --erase-size takes decimal, 0x hex, or a K/M suffix such as 2M (1024-based). The range must fit in the 32-bit address space. On a DA1469x it must lie inside 0x16000000–0x17FFFFFF, and it replaces both the 1 MiB default and the LAGER_ERASE_RANGE line of the JLinkScript. On any other target, the range replaces the full chip erase: J-Link runs erase <start> <end>, and OpenOCD runs flash erase_address. A bad range is refused before the CLI contacts the box. A box on 0.50.0 or later accepts the range. On an older box, the CLI refuses the two options before the erase, with a message that names lager update. The box never sees the request, so it never erases its default range in place of yours. On success the CLI prints Erase complete: and the range the box erased, for example Erase complete: 0x16000000-0x161FFFFF (2 MiB), or Erase complete: full chip. A box older than 0.50.0 does not report the range, and the CLI prints Erase complete!. With --json, the erase_range field carries start, end (inclusive), length, source, and text. source is request, script, or default. The field is null for a full chip erase. Failure output: If the erase fails, erase prints Erase failed: and the error, then exits 1. A box on 0.42.0 or later finds a J-Link attach failure itself and returns an error, which the CLI prints after Erase failed:. An older box returns the probe output with no error. The CLI then checks each line of that output. A line fails the erase when it is, starts with, or ends with one of these messages:

ERROR: Could not connect to target.
Could not connect to target.
Could not connect to the target device.
Cannot connect to target.
Failed to power up DAP

For such a line, the CLI prints Erase failed: and the line, then The target was NOT erased. Check that it is connected and powered. If the output contains none of these lines, erase exits 0. Examples:

# Erase with confirmation prompt
lager debug erase --box my-lager-box

# Erase without confirmation
lager debug erase --box my-lager-box --yes

# Erase 2 MiB from the start of QSPI on a DA1469x
lager debug erase --box my-lager-box --yes --erase-start 0x16000000 --erase-size 2M

# Erase and halt afterward
lager debug erase --box my-lager-box --yes --halt

`memrd`

Read memory from the target device.

lager debug [NET_NAME] memrd START_ADDR LENGTH [OPTIONS]

Arguments:

START_ADDR - Starting memory address (e.g., 0x20000000)
LENGTH - Number of bytes to read

Options:

--box TEXT - Lager Box name or IP
--json - Output results in JSON format
--halt / --no-halt - Halt device during read (default: no-halt). --no-halt overrides the auto-halt for DA1469x QSPI XIP
--no-reset - DA1469x only. Skip the reset+halt the box performs before the read. A running DA1469x has SWD disabled, so without the reset the read fails — use this only on a blank/awake part to avoid rebooting it

Examples:

# Read 16 bytes of SRAM
lager debug memrd 0x20000000 16 --box my-lager-box

# Read with device halted (more reliable)
lager debug memrd 0x20000000 64 --halt --box my-lager-box

# Output as JSON
lager debug memrd 0x08000000 32 --json --box my-lager-box

# DA1469x: read a blank/awake part without rebooting it
lager debug memrd 0x20000000 16 --no-reset --box my-lager-box

Output:

0x20000000:	0x00	0x01	0x02	0x03	0x04	0x05	0x06	0x07
0x20000008:	0x08	0x09	0x0a	0x0b	0x0c	0x0d	0x0e	0x0f

`status`

Show debug net status and configuration information.

lager debug [NET_NAME] status [OPTIONS]

Options:

--box TEXT - Lager Box name or IP

Examples:

lager debug status --box my-lager-box
lager debug debug1 status --box my-lager-box

Output:

Debug Net Information:
  Name: debug1
  Device Type: STM32F407VG
  Architecture: ARM Cortex-M4
  Probe: J-Link
  GDB server running: True
  Target attached: Yes

GDB server running is about the process on the box. Target attached is about the part: the box reads the target to answer it. The two fields differ, so the CLI reports them separately. A gdbserver can outlive the device it drove, and a command that flashes or erases cares about the second field, not the first. To answer Target attached, status reads the Cortex-M CPUID register through the running GDB server. The read does not halt the core. A slow probe can make status take up to 20 seconds. Target attached reads No in two cases:

No GDB server runs for the probe.
The log of the GDB server records a failed attach.

Target attached reads Unknown when the box cannot establish an answer. These cases give that result:

The box is older than this field.
The probe cannot run, because a debugger already holds the session.
The read of the register timed out.
OpenOCD gave an empty reply.

Unknown does not mean that the target is absent.

`health`

Check debug service health and resource usage. The output includes a Features line: the capabilities the box’s debug service supports beyond its original requests, such as erase_range for --erase-start and --erase-size. A box that predates the list prints none reported.

lager debug [NET_NAME] health [OPTIONS]

Options:

--box TEXT - Lager Box name or IP
--verbose - Show detailed health information

Examples:

# Basic health check
lager debug health --box my-lager-box

# Detailed health information
lager debug health --box my-lager-box --verbose

Output (verbose):

Debug Service Health:
  Status: healthy
  Version: 1.2.0
  Uptime: 2.5 days (216000s)
  J-Link Running: True
  J-Link PID: 12345
  GDB Controllers Cached: 1
  Active Connections: 1

Listing Debug Nets

When invoked with only --box and no subcommand, lists all debug nets on the Lager Box:

lager debug --box my-lager-box

Output:

Name    Net Type  Instrument  Channel      Address
debug1  debug     J-Link      STM32F407VG  USB::001::002
debug2  debug     CMSIS-DAP   nRF52840     USB::001::003

RTT (Real-Time Transfer) Logging

RTT provides low-latency logging over the debug probe. Use the --rtt or --rtt-reset flags with gdbserver:

# Stream RTT after connecting
lager debug gdbserver --box my-lager-box --rtt

# Reset device and capture boot messages
lager debug gdbserver --box my-lager-box --rtt-reset

# Pipe to defmt-print for formatted output
lager debug gdbserver --box my-lager-box --rtt 2>/dev/null | defmt-print -e firmware.elf

Decoding defmt logs

Most Rust (and much C) firmware logs via defmt, a compressed binary format. Raw RTT bytes from defmt firmware are not human-readable. defmt-print must decode them, and it needs the exact ELF that is flashed on the target.

# Flash the build under test, then stream + decode a bounded window
lager debug SWD flash --elf build/app.elf --box my-lager-box
timeout 15 lager debug SWD gdbserver --box my-lager-box --rtt-reset 2>/dev/null \
  | defmt-print -e build/app.elf

Two things to watch:

Redirect stderr. The RTT payload is written to stdout; status messages (JLinkGDBServer started!, etc.) go to stderr. Pipe stdout only — append 2>/dev/null (or 2>debug.log) so status lines never corrupt defmt-print’s input.
The stream never ends. --rtt runs until the process is killed. In scripts or non-interactive sessions, wrap it in timeout <seconds> to capture a fixed window. When you kill the lager process, the pipe closes and defmt-print exits on EOF.

Install defmt-print with cargo install defmt-print on the machine where you run the pipe (the same machine that holds the .elf).

Interactive (bi-directional) RTT

Add --interactive to send data to the target as well as read from it. Whatever you type on stdin is forwarded to the target’s RTT down-channel, which is how firmware that exposes a command console over RTT is driven:

lager debug SWD gdbserver --box my-lager-box --rtt --interactive

stdout remains the raw up-channel byte stream, so this composes with defmt-print exactly as plain --rtt does:

lager debug SWD gdbserver --box my-lager-box --rtt --interactive 2>/dev/null \
  | defmt-print -e build/app.elf

Your keystrokes are echoed by your terminal, not written to stdout, so they never reach the decoder. Use --rtt-channel N to work on a channel other than 0; the same channel is used in both directions.

The firmware must declare an RTT down buffer on the channel you use. The defmt-rtt crate sets up only the up buffer. With no down buffer, the target discards what it receives and gives no indication that it did so. That reads as a host-side failure, but it is not one. Firmware using rtt-target’s down channel, or a SEGGER_RTT down buffer, works as expected.

--interactive expects a terminal. In scripts and other non-interactive contexts, keep using plain --rtt with timeout. Only one interactive session can be attached to a given probe and channel at a time, because the underlying RTT connection accepts a single client. A second attempt is refused rather than silently taking the stream from the first.

Typical Workflows

Development Cycle

# Flash and debug
lager debug flash --elf build/app.elf --box my-lager-box
lager debug gdbserver --box my-lager-box --halt

# In another terminal, connect GDB
arm-none-eabi-gdb build/app.elf -ex 'target remote <BOX_IP>:2331'

RTT Debugging

# Flash for a clean RTT state (erase happens by default)
lager debug flash --elf build/app.elf --box my-lager-box

# Start GDB server and stream RTT with boot capture
lager debug gdbserver --box my-lager-box --rtt-reset

Memory Inspection

# Halt device and read memory
lager debug gdbserver --box my-lager-box --halt
lager debug memrd 0x20000000 256 --box my-lager-box

Clean Up

# Stop debug session
lager debug disconnect --box my-lager-box

# Full chip erase before new project
lager debug erase --box my-lager-box --yes

JLinkScript Support

JLinkScript files allow you to customize J-Link debug probe behavior for specific hardware configurations. They can handle custom reset sequences, clock initialization, pin configurations, and other device-specific operations that the standard J-Link connection flow does not cover.

Configuring JLinkScript

There are three ways to attach a J-Link script to a debug net: 1. During net creation:

lager nets add debug1 debug STM32F407VG USB::001::002 \
  --jlink-script ./my_device.JLinkScript --box my-lager-box

2. On an existing net:

lager nets set-script debug1 ./my_device.JLinkScript --box my-lager-box

3. Per-project in .lager config:

{
  "DEBUG": {
    "debug1": "./scripts/my_device.JLinkScript"
  }
}

Script Priority

When both a net-level script (stored on the box via set-script) and a project-level script (in .lager config) exist, the project-level script takes priority. This allows you to override the box-stored script for specific projects.

Managing Scripts

# View attached script
lager nets show-script debug1 --box my-lager-box

# Save script to local file
lager nets show-script debug1 --box my-lager-box > script.JLinkScript

# Remove script from net
lager nets remove-script debug1 --box my-lager-box

Once attached, the script is used automatically for all debug operations (connect, flash, erase, reset) without any additional flags.

DA1469x Targets

A device name that contains DA1469 selects the DA1469x handling. On this family, flash and erase act on the external QSPI flash. The CPU maps that flash for execute-in-place (XIP) at 0x16000000.

Addresses. Pass an absolute XIP address, for example --bin build/app.bin,0x16000000. Do not pass a flash offset.
Erase. By default, erase and the erase before flash erase 1 MiB from 0x16000000 on both backends. This family never gets a full chip erase.
Erase range. --erase-start and --erase-size set the range on both backends, and it must lie inside 0x16000000–0x17FFFFFF. On J-Link, when the two options are absent, a line such as LAGER_ERASE_RANGE: 0x16000000 0x160FFFFF in the JLinkScript of the net sets the range. The J-Link backend then erases that inclusive range. The options win over the script line, and the script line wins over the default.

On an OpenOCD probe, mainline OpenOCD has no driver for this QSPI flash. The box runs a RAM-resident flash loader instead:

An address outside 0x16000000–0x17FFFFFF is refused before the box touches the probe.
Use --bin. The loader writes the bytes of the file unchanged, so it does not decode a .hex or .elf file.
Put flash_loader.elf and flash_loader.elf.bin in ~/third_party/customer-binaries/openocd/flash-loaders/da1469x/ on the box host. The container sees that directory as /home/www-data/customer-binaries/openocd/flash-loaders/da1469x/.
To use a different parent directory, set LAGER_FLASH_LOADERS_DIR to a container path with lager box-config env set, then run lager box-config apply.
OpenOCD has no built-in target config for this family. Attach one to the net with lager nets set-script or lager nets add --openocd-config.
A dropped debug read does not stop the loader. The loader retries the read until the deadline of its step. The deadlines are 10 s for boot, 60 s per MiB for erase, and 30 s per program chunk.

A loader failure names the last progress line that the loader printed:

DA1469x flash_loader flash failed after '<last progress line>': <cause>. The QSPI erase already ran, so the board may be left blank until a flash succeeds.

If the message says that the QSPI erase already ran, the board can be blank. Flash it again before you reset it.

# Flash a DA1469x image at the start of QSPI
lager debug SWD flash --bin build/app.bin,0x16000000 --box my-lager-box

Supported Debug Probes

The box selects the backend from the USB vendor ID of the probe.

Probe	Backend	Notes
J-Link	JLinkGDBServer	Full feature support, RTT, JLinkScript
J-Link Plus	JLinkGDBServer	Full feature support, RTT, JLinkScript
Flasher ARM	JLinkGDBServer	Production programming
CMSIS-DAP (Arm DAPLink)	OpenOCD	Open source, wide device support
ST-Link	OpenOCD	STM32 devices
Raspberry Pi Debug Probe (Picoprobe)	OpenOCD	CMSIS-DAP firmware
FTDI adapters (FT2232H, FT232H, FT4232H)	OpenOCD	Uses an MPSSE channel
Atmel EDBG	OpenOCD	Microchip evaluation boards
Olimex ARM-USB-OCD-H	OpenOCD	FTDI adapter

Supported Device Families

Lager supports 70+ ARM Cortex-M device families with automatic architecture detection. The device type is specified as the channel when creating a debug net (e.g., STM32F407VG, nRF52840).

Cortex-M0/M0+ (ARMv6-M)

Family	Manufacturer
RP2040	Raspberry Pi
nRF51	Nordic Semiconductor
STM32C0	STMicroelectronics
STM32F0	STMicroelectronics
STM32G0	STMicroelectronics
STM32L0	STMicroelectronics
LPC8xx, LPC11xx	NXP
ATSAMD, ATSAML, ATSAMC	Microchip/Atmel
EFM32 Zero Gecko	Silicon Labs

Cortex-M3 (ARMv7-M)

Family	Manufacturer
STM32F1	STMicroelectronics
STM32F2	STMicroelectronics
STM32L1	STMicroelectronics
LPC13xx, LPC17xx, LPC18xx	NXP
LM3, LM4F (Stellaris/Tiva-C)	Texas Instruments
EFM32 Giant/Leopard/Wonder Gecko	Silicon Labs

Cortex-M4/M7 (ARMv7E-M)

Family	Manufacturer
nRF52	Nordic Semiconductor
STM32F3	STMicroelectronics
STM32F4	STMicroelectronics
STM32F7	STMicroelectronics
STM32G4	STMicroelectronics
STM32H7	STMicroelectronics
STM32L4	STMicroelectronics
STM32WB	STMicroelectronics
STM32WL	STMicroelectronics
MKxxxx (Kinetis K)	NXP
LPC4xxx, LPC54xxx	NXP
MIMXRT (i.MX RT)	NXP
TM4C	Texas Instruments
MSP432	Texas Instruments
CC26xx, CC13xx	Texas Instruments
ATSAM4, ATSAME, ATSAMS, ATSAMV	Microchip/Atmel
EFM32, EFR32	Silicon Labs
CY, PSoC	Infineon
DA145x, DA146x, DA148x	Dialog Semiconductor

Cortex-M23 (ARMv8-M Base)

Family	Manufacturer
LPC55S0x	NXP

Cortex-M33/M55 (ARMv8-M Main)

Family	Manufacturer
nRF53	Nordic Semiconductor
nRF91	Nordic Semiconductor
STM32L5	STMicroelectronics
STM32U5	STMicroelectronics
STM32H5	STMicroelectronics
STM32WBA	STMicroelectronics
LPC55S	NXP
R7FA (Renesas RA)	Renesas

Devices not in the table above default to Cortex-M4 (ARMv7E-M) architecture. If your device is not detected correctly, specify the full device part number (e.g., STM32F407VG rather than just STM32F4) when creating the debug net.

Notes

Debug nets are created with lager nets add <name> debug <device_type> <address>
The system auto-connects when needed for commands like flash and reset
Before flash, erase and reset run, the CLI checks that the target answers. If the GDB server is up but the target does not answer, the CLI prints The debug session is up, but the target does not answer; reconnecting... and starts a new session. If that reconnect fails, the command exits 1.
flash erases before programming by default, giving a clean state for RTT initialization (use --no-erase to opt out)
RTT streaming requires the device to have RTT support in firmware
Memory reads are more reliable with --halt to pause the CPU
Use lager debug health --verbose to diagnose connection issues
JLinkScript files are base64-encoded for storage and decoded automatically on the box

​Syntax

​Global Options

​Commands

​Command Reference

​gdbserver

​disconnect

​flash

​reset

​erase

​memrd

​status

​health

​Listing Debug Nets

​RTT (Real-Time Transfer) Logging

​Decoding defmt logs

​Interactive (bi-directional) RTT

​Typical Workflows

​Development Cycle

​RTT Debugging

​Memory Inspection

​Clean Up

​JLinkScript Support

​Configuring JLinkScript

​Script Priority

​Managing Scripts

​DA1469x Targets

​Supported Debug Probes

​Supported Device Families

​Cortex-M0/M0+ (ARMv6-M)

​Cortex-M3 (ARMv7-M)

​Cortex-M4/M7 (ARMv7E-M)

​Cortex-M23 (ARMv8-M Base)

​Cortex-M33/M55 (ARMv8-M Main)

​Notes

​See Also

Syntax

Global Options

Commands

Command Reference

`gdbserver`

`disconnect`

`flash`

`reset`

`erase`

`memrd`

`status`

`health`

Listing Debug Nets

RTT (Real-Time Transfer) Logging

Decoding defmt logs

Interactive (bi-directional) RTT

Typical Workflows

Development Cycle

RTT Debugging

Memory Inspection

Clean Up

JLinkScript Support

Configuring JLinkScript

Script Priority

Managing Scripts

DA1469x Targets

Supported Debug Probes

Supported Device Families

Cortex-M0/M0+ (ARMv6-M)

Cortex-M3 (ARMv7-M)

Cortex-M4/M7 (ARMv7E-M)

Cortex-M23 (ARMv8-M Base)

Cortex-M33/M55 (ARMv8-M Main)

Notes

See Also