2025-05-05 12:00 AM
Dear all,
I have purchased the NUCLEO-H7S3L8. I am facing an issue when trying to debug a basic (blank) project. The Debugger is unable to connect to the target. Here is the console output :
"
STMicroelectronics ST-LINK GDB server. Version 7.10.0
Copyright (c) 2025, 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.19.0
-------------------------------------------------------------------
Log output file: /tmp/STM32CubeProgrammer_fldzzj.log
ST-LINK SN : 0020002B3433511830343835
ST-LINK FW : V3J16M7
Board : NUCLEO-H7S3L8
Voltage : 3,30V
SWD freq : 8000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x485
Revision ID : Rev B
Device name : STM32H7RSxx
Flash size : 64 KBytes (default)
Device type : MCU
Device CPU : Cortex-M7
BL Version : 0xE4
Opening and parsing file: ST-LINK_GDB_server_YZEder.srec
Memory Programming ...
File : ST-LINK_GDB_server_YZEder.srec
Size : 6.39 KB
Address : 0x08000000
Erasing memory corresponding to sector 0:
Erasing internal memory sector 0
Download in Progress:
File download complete
Time elapsed during download operation: 00:00:00.057
-------------------------------------------------------------------
STM32CubeProgrammer v2.19.0
-------------------------------------------------------------------
Log output file: /tmp/STM32CubeProgrammer_MGG0Vd.log
Error: Unable to connect to the target device, Access port is not valid.
Encountered Error when opening /opt/st/stm32cubeide_1.18.1/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_2.2.100.202412061334/tools/bin/STM32_Programmer_CLI
Error in STM32CubeProgrammer
Shutting down...
Exit.
"
The project I am trying to debug is the standard code generated when creating a new project in STM32CubeIDE. The only thing I changed is the Debugger Configuration (I changed it iaw this guide : https://community.st.com/t5/stm32-mcus/stm32cubeide-how-to-debug-an-stm32h7rx-sx-project-without/ta-p/737120).
I have already tried a mass erase (using the BOOT0 pin and STM32 Programmer) but the issue persists.
Can someone assist me on how to launch a Debug session (even from an Example project) with the NUCLEO-H7S3L8 ?
Solved! Go to Solution.
2025-05-07 1:59 AM
Hi all,
I have checked the FLASH registers using STM32CubeProgrammer and the NVSTATE is programmed to 0xB4, which corresponds to OPENED according to the Reference Manual :
So the issue is not a wrong configuration of AP1, it is a wrong selection of the AP inside the IDE. I recreated a new blank project for the NUCLEO-H7S3L8 and confirmed the default access port is 0. Only after changing AP to 1 I was able to Debug the program.
A fix in STM32CubeIDE should be provided as it makes no sense to configure the debugger by default to a port which is closed.
2025-05-05 1:33 AM
Hello @neo-knight-td and welcome to the community;
Are you able to connect your board using STM32CubeProgrammer toolchain?
Could you please
I hope this help you.
Thank you.
Kaouthar
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-05-05 1:51 AM
Hi,
so you are on a Linux system, IDE 1.18.1 ; can you debug any other board ?
because maybe your system missing the outdated libs, libncurses.so.5 etc, IDE still expects.
Read here in forum about solutions... just search : libncurses.so.5 .
2025-05-05 5:17 AM
Hi @KDJEM.1 ,
As I said, I am able to connect with STM32CubeProgrammer when setting the BOOT0 pin high.
I tried the two power configuration :
/*!< Supply configuration update enable */
HAL_PWREx_ConfigSupply(PWR_DIRECT_SMPS_SUPPLY);
Or
/*!< Supply configuration update enable */
HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);
None has worked for me.
I have done a mass erase using STM32CubeProgrammer, but I am still not able to debug the base project with that.
I looked at the HSLV bits. I don't see them being modified anywhere in the code. By default (after the mass erase), they are unset.
I am not trying an example yet. I have just opened a new blank project for the NUCLEO-H7S3L8 but even this is undebuggable.
Do you have any other suggestion ?
2025-05-06 5:16 AM - edited 2025-05-06 5:21 AM
Hello, @neo-knight-td
I am facing a similar problem right now, but in VSCode (on Windows 10) using STM32CubeCLT v1.18.0 (same CubeProgrammer version and compiler are used when installing CubeIDE 1.18 to my knowledge), and for the MCU I use STM32H523CET6 and STM32WB55RGV. For some reason I am able to flash firmware onto them with success, able to establish a connection from CubeProgrammer (v2.19.0), but I am unable to debug them, resulting in the same warning/error that You mentioned in the first post "Waiting for debugger connection...". Same problem when using STM32CubeCLT v1.17.0.
What I did to fix it was installing STM32CubeCLT v1.16.0, and changed the paths for the cubeprogrammer, gdb and gdbserver for the ones that got installed with the older STM32CubeCLT (v1.16.0) version.
I have no idea why this is happening do only debugging with the newer versions (starting from CubeProgrammer v2.18.0 and STM32CubeCLT v1.17.0), but going back to using STM32CubeCLT v1.16.0 fixed it for now. If You do not wish to install the STM32CubeCLT and then changing the paths, then maybe installing older version of CubeIDE v1.16.0(1) will solve the issue for now until a fix has been released.
EDIT1: Using ST-Link v2 with firmware version V2J45S7 to flash and debug the firmware.
2025-05-07 12:55 AM - edited 2025-05-07 12:55 AM
Hi @AScha.3,
Thanks for the tip. Unfortunately, changing to version STM32CubeIDE did not solve my issue.
However, after performing an Xth reset with the STM32CubeProgrammer, I remarked something in the logs :
The AP0 seemed to be closed. I thus modified the AP into STM32CubeIDE Debugger Configuration :
After that, I was able to Debug the board.
@KDJEM.1, do you have an idea why the AP used by default (AP0) in STM32CubeIDE Debugger is closed ?According to the Reference Manual (RM0477), there are two Debug APs : APB-AP (DBGMCU) and AHB-AP (Cortex M7) :
AHB-AP (Cortex M7) might be closed when debug is disabled (NVSTATE = CLOSE). It then needs to be opened via APB-AP :
Is the base project for NUCLEO-H7S3L8 configuring NVSTATE = CLOSE by default in the FLASH register ? Why is it the case ? If it is the case, why not adapting the default debugger configuration ?
Thank you in advance for your inputs.
2025-05-07 1:59 AM
Hi all,
I have checked the FLASH registers using STM32CubeProgrammer and the NVSTATE is programmed to 0xB4, which corresponds to OPENED according to the Reference Manual :
So the issue is not a wrong configuration of AP1, it is a wrong selection of the AP inside the IDE. I recreated a new blank project for the NUCLEO-H7S3L8 and confirmed the default access port is 0. Only after changing AP to 1 I was able to Debug the program.
A fix in STM32CubeIDE should be provided as it makes no sense to configure the debugger by default to a port which is closed.