The target extended-remote /dev/ttyACM0 GDB command seems to be buggy - at least for Zephyr firmwares. It gets stuck as follows:
(gdb) target extended-remote /dev/ttyACM0
Remote debugging using /dev/ttyACM0
arch_irq_unlock (key=8) at zephyr/include/zephyr/arch/riscv/arch.h:259
259 __asm__ volatile ("csrs mstatus, %0"
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
arch_cpu_idle () at zephyr/arch/riscv/core/cpu_idle.c:14
14 irq_unlock(MSTATUS_IEN);
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
arch_cpu_idle () at zephyr/arch/riscv/core/cpu_idle.c:14
14 irq_unlock(MSTATUS_IEN);
(gdb)
Continuing.
<Never ends>
With target remote /dev/ttyACM0, debugging works great!
(gdb) target remote /dev/ttyACM0
(gdb) break k_msleep
Breakpoint 1 at 0xdc6: file zephyr/include/generated/zephyr/syscalls/kernel.h, line 135.
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) c
Continuing.
Breakpoint 1, k_msleep (ms=1000) at zephyr/include/zephyr/kernel.h:491
491 return k_sleep(Z_TIMEOUT_MS(ms));
(gdb) c
Continuing.
Breakpoint 1, k_msleep (ms=1000) at zephyr/include/zephyr/kernel.h:491
491 return k_sleep(Z_TIMEOUT_MS(ms));
(gdb) c
Continuing.
Zephyr: https://www.zephyrproject.org/
The
target extended-remote /dev/ttyACM0GDB command seems to be buggy - at least for Zephyr firmwares. It gets stuck as follows:With
target remote /dev/ttyACM0, debugging works great!Sample blinky firmware: zephyr.elf.zip
Related: https://github.com/zephyrproject-rtos/zephyr/pull/73761.