NUCLEO-G431KB ERROR gdb-server.c: cannot recv: -2

[keck9939]

• Programmer/board type: NUCLEO-G431KB
• Operating system an version: Linux raspberrypi 6.12.20+rpt-rpi-2712
• stlink tools version and/or git commit hash: 5259daa
• stlink commandline tool name: st-util
• Target chip (and board, if applicable): NUCLEO-G431KB

When remote debugging from Cube IDE 1.18.1 (Windows) to st-util GDB server on a RaspberryPi5, at the IDE I get the error:
Could not verify ST device. Please verify that the latest version of the GDB server is used for the connection.

At the RaspberryPi I get:

keck@raspberrypi:~/git/stlink $ st-util -p 3333
st-util 1.8.0-103-g5259daa
2025-04-22T17:11:06 INFO common_legacy.c: STM32G43x_G44x: 32 KiB SRAM, 128 KiB flash in at least 2 KiB pages.
2025-04-22T17:11:06 INFO gdb-server.c: Listening at *:3333...
2025-04-22T17:11:17 INFO common_legacy.c: STM32G43x_G44x: 32 KiB SRAM, 128 KiB flash in at least 2 KiB pages.
2025-04-22T17:11:17 INFO gdb-server.c: Found 6 hw breakpoint registers
2025-04-22T17:11:17 INFO gdb-server.c: GDB connected.
2025-04-22T17:11:19 ERROR gdb-server.c: cannot recv: -2

and st-util quits.

The tools were built on the Pi following the build instructions.

[keck9939]

I used Wireshark to capture the conversation from the IDE to the debugger stub, for both the st-util stub on the Pi and ST's stub on the Windows PC. One thing I notice is the difference in the memory map returned by st-util. It does not appear to be correct. I have attached localGDB.pdf (ST's stub on the PC) and remoteGDB.pdf (st-util on the Pi) which shows Wireshark's analyzed conversations.

remoteGDB.pdf
localGDB.pdf

[jcw]

Perhaps this is not related, but I see frequent USB bus hangs when doing st-flash writes to a Nucleo-STM32G431KB (LIBUSB_ERROR_TIMEOUT, the x64 host needs a power-cycle to recover). Never happened with the other 10 or so attached boards, so far. The G431 boards have an ST-Link V3 on board, the others V2.1, FWIW.

[keck9939]

I've seen timeouts when debugging locally primarily when using live expressions. I found that things improve considerably if I re-flash the ST-LINK so it does not support the mass storage capability. Also, slowing down the SWD clock rate helps.
I do not think however that this is related to the remote debug issue I'm seeing here.