Unable to connect to target device - STM32H7S3L8H6 (NUCLEO-H7S3L8)

[neo-knight-td]

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 ?

 

 

 

 

 

[KDJEM.1]

Hello @neo-knight-td and welcome to the community;

 

Are you able to connect your board using STM32CubeProgrammer toolchain?

Could you please

• Try to refer and follow the steps shared in this FAQ: How can I recover my STM32H7 board after facing a power configuration deadlock?
• Try to upgrade Firmware using STM32CubeProgrammer and erase external memory.
• If you run an STM32Cube_FW_H7RS example, it is recommended to check the readme file for the HSLV bits level. Please take look at this FAQ.

I hope this help you.

Thank you.

Kaouthar

[neo-knight-td]

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 ?

[AScha.3]

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 .

[Sander_UP]

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.

[neo-knight-td]

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.

 

[neo-knight-td]

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.