Debug-Error on a STM32 Board - Error in final launch sequence

[BuGe]

Hello Community,

we're trying to debug an STM32 image (kernel-version V6.1.28) on the M4 core using STLINK-V3SET debugger via STM32CubeIDE (V1.16.0) and getting the following error:

Error in final launch sequence: Failed pre launch (s. attached screenshot).

The directory /lib/firmware has space and is writeable.

Does anyone have an idea what the problem is?

The content of our local.conf:

MACHINE ??= 'txmp-1571'
DL_DIR ?= "${BSPDIR}/downloads"
SSTATE_DIR ?= "${BSPDIR}/sstate-cache"
DISTRO ?= 'karo-wayland'
DISTRO_FEATURES:append = " alternatives-symlinks-relative"
PACKAGE_CLASSES ?= "package_rpm"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
HALT,${TMPDIR},100M,1K \
HALT,${DL_DIR},100M,1K \
HALT,${SSTATE_DIR},100M,1K \
HALT,/tmp,10M,1K"
SSTATE_MIRRORS ?= "\
file://.* http://sstate.karo-electronics.de/PATH;downloadfilename=PATH \
"
PACKAGECONFIG:append:pn-qemu-native = " sdl"
PACKAGECONFIG:append:pn-nativesdk-qemu = " sdl"
CONF_VERSION = "2"
BB_HASHSERVE = ""
BB_SIGNATURE_HANDLER = "OEBasicHash"
VIRTUAL-RUNTIME_dev_manager ??= "udev"
ROOT_HOME = "/root"
SANITY_TESTED_DISTROS:append = " devuan-4"
unset SOURCE_DATE_EPOCH
REPRODUCIBLE_TIMESTAMP_ROOTFS = ""
KERNEL_DEBUG_TIMESTAMPS = "1"
DEFAULT_TIMEZONE = "Europe/Berlin"
IMAGE_INSTALL:append = " psplash nano openssh-sftp-server"

[DStau.1]

Hi there,

I maybe have the same issue. I try to debug the M4 core of a STM32MP157. I'm using the latest CubeIDE under Windows 10 LTS. I was able to debug the older Kernel 5.x images. The 6.x Kernel doesn't work at all.

I can debug my FreeRTOS devices (STM32H7 and F7) without any issues.

[UStei.1]

create the folder /lib/firmware by hand. STM32CubeIDE obviously expects it in the file system and is not able to create it by itself if it is not available.

[BuGe]

When I create this folder manually I get the new error: "Failed to execute MI command":

[UStei.1]

it seems that the openocd server cannot be started correctly. The console output shows:

Open On-Chip Debugger 0.12.0+dev-00597-ga5a21219f (2024-06-03-11:02) [https://github.com/STMicroelectronics/OpenOCD]

Licensed under GNU GPL v2

For bug reports, read

http://openocd.org/doc/doxygen/bugs.html

srst_only srst_pulls_trst srst_gates_jtag srst_open_drain connect_deassert_srst

Info : Listening on port 6666 for tcl connections

Info : Listening on port 4444 for telnet connections

Info : STLINK V3J15M7B5S1 (API v3) VID:PID 0483:374F

Info : Target voltage: 3.287302

Error: init mode failed (unable to connect to the target)

when I add the -d option into the command line, it shows that it fails caused by an USB error:

Open On-Chip Debugger 0.12.0+dev-00597-ga5a21219f (2024-06-03-11:02) [https://github.com/STMicroelectronics/OpenOCD]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html

...

Debug: 237 6 stlink_usb.c:5155 stlink_dap_init(): stlink_dap_init()
Debug: 238 6 stlink_usb.c:3732 stlink_open(): stlink_open
Debug: 239 6 stlink_usb.c:3746 stlink_open(): transport: 3 vid: 0x0483 pid: 0x3748 serial:
Debug: 240 6 stlink_usb.c:3746 stlink_open(): transport: 3 vid: 0x0483 pid: 0x374b serial:
Debug: 241 6 stlink_usb.c:3746 stlink_open(): transport: 3 vid: 0x0483 pid: 0x374d serial:
Debug: 242 6 stlink_usb.c:3746 stlink_open(): transport: 3 vid: 0x0483 pid: 0x374e serial:
Debug: 243 6 stlink_usb.c:3746 stlink_open(): transport: 3 vid: 0x0483 pid: 0x374f serial:
Debug: 244 6 stlink_usb.c:3746 stlink_open(): transport: 3 vid: 0x0483 pid: 0x3752 serial:
Debug: 245 6 stlink_usb.c:3746 stlink_open(): transport: 3 vid: 0x0483 pid: 0x3753 serial:
Debug: 246 6 stlink_usb.c:3746 stlink_open(): transport: 3 vid: 0x0483 pid: 0x3754 serial:
Debug: 247 6 stlink_usb.c:3746 stlink_open(): transport: 3 vid: 0x0483 pid: 0x3755 serial:
Debug: 248 6 stlink_usb.c:3746 stlink_open(): transport: 3 vid: 0x0483 pid: 0x3757 serial:
Info : 249 19 stlink_usb.c:1475 stlink_usb_version(): STLINK V3J15M7B5S1 (API v3) VID:PID 0483:374F
Debug: 250 19 stlink_usb.c:1696 stlink_usb_exit_mode(): MODE: 0x01
Info : 251 19 stlink_usb.c:1507 stlink_usb_check_voltage(): Target voltage: 3.269841
Debug: 252 19 stlink_usb.c:1764 stlink_usb_init_mode(): MODE: 0x01
Debug: 253 19 stlink_usb.c:3130 stlink_dump_speed_map(): Supported clock speeds are:
Debug: 254 19 stlink_usb.c:3133 stlink_dump_speed_map(): 21333 kHz
Debug: 255 19 stlink_usb.c:3133 stlink_dump_speed_map(): 16000 kHz
Debug: 256 19 stlink_usb.c:3133 stlink_dump_speed_map(): 12000 kHz
Debug: 257 19 stlink_usb.c:3133 stlink_dump_speed_map(): 8000 kHz
Debug: 258 19 stlink_usb.c:3133 stlink_dump_speed_map(): 1777 kHz
Debug: 259 19 stlink_usb.c:3133 stlink_dump_speed_map(): 750 kHz
Debug: 260 19 stlink_usb.c:1132 stlink_usb_error_check(): unknown/unexpected STLINK status code 0x5
Error: 261 19 stlink_usb.c:3787 stlink_open(): init mode failed (unable to connect to the target)
Debug: 262 19 stlink_usb.c:1696 stlink_usb_exit_mode(): MODE: 0x01
Debug: 263 20 command.c:529 exec_command(): Command 'init' failed with error code -4
User : 264 20 command.c:601 command_run_line():
Debug: 265 20 breakpoints.c:328 breakpoint_remove_all_internal(): [STM32MP157CAAx.ap1] Delete all breakpoints
Debug: 266 20 mem_ap.c:71 mem_ap_deinit_target(): mem_ap_deinit_target
Debug: 267 20 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
Debug: 268 20 breakpoints.c:328 breakpoint_remove_all_internal(): [STM32MP157CAAx.ap2] Delete all breakpoints
Debug: 269 20 mem_ap.c:71 mem_ap_deinit_target(): mem_ap_deinit_target
Debug: 270 20 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
Debug: 271 20 breakpoints.c:328 breakpoint_remove_all_internal(): [STM32MP157CAAx.axi] Delete all breakpoints
Debug: 272 20 mem_ap.c:71 mem_ap_deinit_target(): mem_ap_deinit_target
Debug: 273 20 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
Debug: 274 20 breakpoints.c:328 breakpoint_remove_all_internal(): [STM32MP157CAAx.cpu0] Delete all breakpoints
Debug: 275 20 breakpoints.c:328 breakpoint_remove_all_internal(): [STM32MP157CAAx.cpu1] Delete all breakpoints
Debug: 276 20 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
Debug: 277 20 breakpoints.c:328 breakpoint_remove_all_internal(): [STM32MP157CAAx.cpu1] Delete all breakpoints
Debug: 278 20 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
Debug: 279 20 breakpoints.c:328 breakpoint_remove_all_internal(): [STM32MP157CAAx.cm4] Delete all breakpoints
Debug: 280 20 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
Debug: 281 21 arm_adi_v5.c:1217 dap_put_ap(): refcount AP#0x1 put 2
Debug: 282 21 arm_adi_v5.c:1217 dap_put_ap(): refcount AP#0x1 put 1
Debug: 283 21 arm_adi_v5.c:1217 dap_put_ap(): refcount AP#0x1 put 0
Debug: 284 21 arm_adi_v5.c:1217 dap_put_ap(): refcount AP#0x2 put 0

[STea]

Hello @BuGe @UStei.1 and @DStau.1 ,

Did you follow steps of the following Wiki page?

If yes, could you please confirm that you had the same settings and are still unable to open a debug session?
because I'm able to establish connection with CubeIDE 1.15.1 and latest image version available stm32mp1-openstlinux-6.1-yocto-mickledore-mpu-v24.06.26 following the steps in the mentioned above Wiki page.

Regards

[UStei.1]

Hello STea,

yes I know this Wiki of course and have the same settings. The only thing I changed was setting the interface from SWD to JTAG, because my baseboard provides only a parallel JTAG connector.

Obviously, you changed the debug probe field from OpenOCD to GDB server. Doing that here, I get the following  log file attached (st-link_gdbserver_log.txt)

On my Linux debug console, I can see the firmware booting:

root@qsmp-1570:/home# [ 2156.292441] remoteproc remoteproc0: powering up m4
[ 2156.302348] remoteproc remoteproc0: Booting fw image OpenAMP_TTY_echo_CM4.elf, size 2687680
[ 2156.310558] rproc-virtio rproc-virtio.1.auto: assigned reserved memory node vdev0buffer@10042000
[ 2156.320231] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 2156.325501] rproc-virtio rproc-virtio.1.auto: registered virtio0 (type 7)
[ 2156.332357] remoteproc remoteproc0: remote processor m4 is now up
[ 2156.338129] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty addr 0x400
[ 2156.349738] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty addr 0x401

also /dev/ttyRPMSG0/1 will be established.

in the Reset behaviour field of the debugger settings I have choosen None.

Is this correct? I wonder that the M4 firmware is obviously started, I would have expected that this is done by the debugger?