2022-03-14 03:23 PM
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
2022-03-17 03:36 AM
Hello there!
A few questions to make the problem a bit more clear to me:
2022-03-17 10:18 AM
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
2022-03-17 10:19 AM
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
2022-12-01 12:57 AM
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?