ST-LINK GDB server doesn't work with new IDE,

[PCout.1]

OpenOCD works, but it's glitchy and has some errors. Before upgrading to STM32CubeIDE 1.8.0, ST-LINK used to work. Upgraded to STM32CubeIDE 1.9.0 and it seems to be failing the same way.

The MCU is an STM32L552RCT6.

Tried different frequencies for SWD, tried creating a new project with a default .ioc configuration and get this. Multiple "Waiting for debugger connection...". A tab opens with: Break at address "0xfffffffe" with no debug information available, or outside of program code.

 
STMicroelectronics ST-LINK GDB server. Version 6.1.0
Copyright (c) 2022, STMicroelectronics. All rights reserved.
 
Starting server with the following options:
 Persistent Mode : Disabled
 Logging Level : 1
 Listen Port Number : 61234
 Status Refresh Delay : 15s
 Verbose Mode : Disabled
 SWD Debug : Enabled
 InitWhile : Enabled
 
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
 -------------------------------------------------------------------
 STM32CubeProgrammer v2.10.0 
 -------------------------------------------------------------------
 
 
 
Log output file: c:\users\dunes\appdata\local\temp\stm32cubeprogrammer_a02748.log
ST-LINK SN : 003A00463438510B34313939
ST-LINK FW : V3J9M3B5S1
Board : STLINK-V3SET
Voltage : 0.00V
SWD freq : 8000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x472
Revision ID : Rev Z
Device name : STM32L5xx
Flash size : 256 KBytes
Device type : MCU
Device CPU : Cortex-M33
BL Version : --
 
 
 
Memory Programming ...
Opening and parsing file: st-link_gdb_server_a02748.srec
 File : st-link_gdb_server_a02748.srec
 Size : 6.30 KB 
 Address : 0x08000000 
 
 
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 3]
Download in Progress:
Error: Fail to write buffer in flash
Error: failed to erase memory
 
 
Error: failed to download Segment[0]
Error: failed to download the File

After doing a full chip erase, unplugging everything and plugging it back in, OpenOCD worked and the debugger reached a breakpoint at HAL_Init(), with this output.

Open On-Chip Debugger 0.11.0+dev-00443-gcf12591 (2022-02-09-13:33) [ST Internal]
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
clock_config
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : STLINK V3J9M3B5S1 (API v3) VID:PID 0483:374F
Info : Target voltage: 0.003204
Error: target voltage may be too low for reliable debugging
Info : clock speed 8000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x0be12477
Info : STM32L552RCTx.cpu: Cortex-M33 r0p2 processor detected
Info : STM32L552RCTx.cpu: target has 8 breakpoints, 4 watchpoints
Info : STM32L552RCTx.cpu: external reset detected
Info : gdb port disabled
Info : starting gdb server for STM32L552RCTx.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
CPU in Non-Secure state
target halted due to debug-request, current mode: Thread 
xPSR: 0xf9000000 pc: 0xfffffffe msp: 0xfffffffc
STM32L552RCTx.cpu TrustZone disabled
STM32L552RCTx.cpu work-area address is set to 0x20000000
Info : device idcode = 0x20016472 (STM32L55/L56xx - Rev 'unknown' : 0x2001)
Info : TZEN = 0 : TrustZone disabled by option bytes
Info : RDP level 0 (0xAA)
Info : flash size = 256kbytes
Info : flash mode : dual-bank
Info : device idcode = 0x20016472 (STM32L55/L56xx - Rev 'unknown' : 0x2001)
Info : TZEN = 0 : TrustZone disabled by option bytes
Info : RDP level 0 (0xAA)
Info : flash size = 256kbytes
Info : flash mode : dual-bank
Info : device idcode = 0x20016472 (STM32L55/L56xx - Rev 'unknown' : 0x2001)
Info : TZEN = 0 : TrustZone disabled by option bytes
Info : RDP level 0 (0xAA)
Info : OTP size is 512 bytes, base address is 0x0bfa0000
Info : New GDB Connection: 1, Target STM32L552RCTx.cpu, state: halted
Error: Failed to read memory at 0xfffffffe
O.K.
 
O.K.:0xE00FEFD0
 
Error: Failed to read memory at 0xfffffffe
Error: Failed to read memory at 0xffffffc0
Error: Failed to read memory at 0xfffffffe
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread 
xPSR: 0xf9000000 pc: 0xfffffffe msp: 0xfffffffc
Info : New GDB Connection: 2, Target STM32L552RCTx.cpu, state: halted
Error: Failed to read memory at 0xfffffffe
target halted due to debug-request, current mode: Thread 
xPSR: 0xf9000000 pc: 0xfffffffe msp: 0xfffffffc
Info : Padding image section 0 at 0x08001934 with 4 bytes (bank write end alignment)
target halted due to debug-request, current mode: Thread 
xPSR: 0xf9000000 pc: 0x080004f0 msp: 0x20040000

What could I do to make the ST-LINK GDB server work?

Thanks

[Markus GIRDLAND]

Hello there!

A few questions to make the problem a bit more clear to me:

1. You mention "before upgrading to 1.8.0", was the last time this was working in 1.7.0 and it doesn't work in neither 1.8.0 nor 1.9.0?
2. The new default projects you tried to create, were these tested on 1.7.0, 1.8.0 and 1.9.0 and it only works in 1.7.0?
3. Is this for one specific board or did you have the opportunity to test multiple boards and you get the same result?

[BBuch.1]

HI Markus, answering for Pedro

Yes 1.7.0 worked properly with debug probe setting to ST-LINK GDB server

The projects build and run on all rev's of IDE, just have issue with debug probe setting, run's with ST-LINK OCD only. However the project was originally developed using 1.7.0.

We have tried new project with 1.9.0 and still have issue with debug probe setting

We have the same issue with multiple devices on four different workstations with four different code developers.

Appreciate any guidance / help you can provide.

Thanks,

Bruce

Dune Labs

EVP

[BBuch.1]

HI Markus, answering for Pedro

Yes 1.7.0 worked properly with debug probe setting to ST-LINK GDB server

The projects build and run on all rev's of IDE, just have issue with debug probe setting, run's with ST-LINK OCD only. However the project was originally developed using 1.7.0.

We have tried new project with 1.9.0 and still have issue with debug probe setting

We have the same issue with multiple devices on four different workstations with four different code developers.

Appreciate any guidance / help you can provide.

Thanks,

Bruce

Dune Labs

EVP

[PCoug.1]

I am encountering this issue on Linux Mint 20.3, GNU gdbserver (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2. I saw in another forum (github.com /STMicroelectronics/OpenOCD/issues/7) that there was a patch to gdb to fix this (sourceware.org /pipermail/gdb-patches/2022-January/185131.html). Seems to add some conditional for 0xfffffffe when Check EXC_RETURN indicator bits.

Could gdb need this patch?