Unable to connect to STM32H7 devices

[Adam BERLINGER]

After reprogramming the STM32H7 device, I can’t connect to the device. Connect under reset doesn’t help. Why?

There are two possible root causes for this issue. The first root cause is more probable and is related to power supply misconfiguration. The second root cause is related to the configuration of the boot process in the option bytes.

1. Possible root cause one (power supply misconfiguration)

This applies to all STM32H7 devices with configurable internal SMPS step-down.
This is most probably related to power-supply configuration. STM32H7 devices with an embedded step-down converter offer different power-supply schemes. The selected configuration depends on external components.
This configuration can be set only once after a power-on reset. Choosing the wrong configuration leads to MCU lock-up. The configuration is done with the following line in the HAL library (usually placed in the SystemClock_Config function):

HAL_PWREx_ConfigSupply(...);

Most of the boards have the supply directly from SMPS (if available in MCU), which requires the above function to be called with PWR_DIRECT_SMPS_SUPPLY parameter. But STM32CubeMX generated projects might have the PWR_LDO_SUPPLY option by default. This parameter can be configured directly in STM32CubeMX, under RCC, and it sets the appropriate project macro to be used during compilation.
Since the configuration can be changed only once after power-on reset, the issue might manifest itself after the next power cycle.
Below is a diagram from a reference manual showing different hardware configurations for the power supply.

The MCU contains a protection mechanism that prevents setting higher voltage from internal SMPS to VCORE (1.8 or 2.5 V). This should prevent damaging the MCU due to misconfiguration.

2. Solutions for root cause one

Since the power-supply is usually configured immediately after reset, it is difficult to connect during that short window.
Solution 1:

1. Plug the board to the power supply, while the reset button is being held low (or NRST pin in general).
2. Keep the reset button low.
3. Connect via STM32CubeProgrammer. When the program starts connecting, release the reset button. Although this requires quite precise timing, it should be easy to achieve.
4. Perform mass erase.
5. Make sure that you fixed the power-supply configuration in your project.

Solution 2:

1. Plug the board to the power supply, while the BOOT0 pin is being held high. This requires the BOOT_CM7_ADD1 to be set to system memory.
2. Keep the BOOT0 button high.
3. Connect via STM32CubeProgrammer. The system bootloader should not modify the power-supply configuration. However, it configures the pins related to bootloader communication interfaces and might disturb external components on the board (this might be critical for custom PCBs).
4. Perform a mass erase.
5. Make sure that you fixed the power-supply configuration in your project.

3. Possible root cause two (Cortex®-M7 boot disabled)

This applies to all STM32H7 devices with dual-core feature.
Other possibility is that the option bytes are configured in a way that only Cortex®-M4 boots after reset (BOOT_CM7/BCM7=0, BOOT_CM4/BCM4=1). Then you need to connect the debugger to Access port 3 (Cortex®-M4), instead of Access port 0 (Cortex®-M7).
For STM32CubeProgrammer versions 2.2.0 and older this does not seem to work. Please use a recent STM32CubeProgrammer version.
For development it is recommended to keep booting from both cores enabled, otherwise some tools/IDEs might not be able to work with the device.

[Zaher]

@Adam BERLINGER​ Thanks a million, this made my day! I thought I bricked my board. In fact, I tried STLink Utility and I came across those different ports, but I was just afraid to give them another shot! This article saved me and my board is back to life again!

[Nsg1987]

Hello @Adam BERLINGER 

Thank you for your post. I want to run Nucleo-H745 board with maximum frequency which is 480 MHz. For this, it was required to change voltage scale to 0 and enable either PWER_LDO_Supply or PWR_EXTERNAL_SOURCE_SUPPLY. I tried with both the options to load the controller, but found error as target not responding.

Could you please suggest correct configuration so that I can operate the borad with 480 MHz for M7 and 240 MHz for M4.

Thanks in advance.

Nikhil 

[Adam BERLINGER]

Hello @Nsg1987,

To use LDO on Nucleo-H745, you need to do HW modifications to the board and also add some additional VCAP capacitors. I think the user manual should provide more information on how to do this, but it might not be trivial task.

Best regards,

Adam

[Nsg1987]

Hello @Adam BERLINGER 

Thank you for your reply. I have gone through the manual and found the same.

/* Exported types ------------------------------------------------------------*/
/* Exported constants --------------------------------------------------------*/
/* Set this define to 1 to OverClocking the system clock to 480MHz*/
#define USE_VOS0_480MHZ_OVERCLOCK 0

/*
!!!Attention!!!
Over clocking the system clock to 480MHz is only available with LDO PWR configuration
by default The NUCLEO-H745ZI-Q board comes with DIRECT_SMPS configuration
in order Over clock the system clock to 480MHz to the nucleo board must modified
to change the PWR path to LDO instead of DIRECT_SMPS

to do so please change the following solder bridges :
- LDO config :
Mount : SB25, R33(0R), SB74
C58 & C54 = 2.2uF instead of 100nF
Removed : SB92, SB79, R35(0R), SB75, SB76

- Direct SMPS config (default config):
Mount : SB92, SB79, R35(0R), SB75, SB76
C58 & C54 = 100nF
Removed : SB25, R33(0R), SB74

Note that the Board HW configuration must match with the FW config
if not will face a deadlock (can't connect the board any more)
the FW PWR configuration correspond in the main.c to the following :
Function SystemClock_Config :
- case of LDO config : HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);
- case of Direct SMPS config : HAL_PWREx_ConfigSupply(PWR_DIRECT_SMPS_SUPPLY);

 

Thanks

Nikhil

[TimC]

@adam BERLINGER​, thanks a bunch for this post, fixed my problem as well!

[Christian_F]

Thanks you @Adam BERLINGER .

[niallp]

This appears to be the problem on our boards, we are using LDO yet the default CubeMX setup for the H725 was for SMPS.

Our attempts to recover via solution #1 haven't succeeded yet though, either no target found or CMD error.

Should the nRST on STLINK probe remain connected in parallel ? (We've tried it both ways) 

software or hardware reset in CubeMX ?

would clock speed make a difference ? (so far just tried default 4000)

[Adam BERLINGER]

Hello @niallp 

The NRST button should be connected in parallel to debug interface, just like it is done on ST evaluation boards.

In STM32CubeProgrammer settings, the reset mode should be set to "Hardware reset" and mode should be set to "Connect under reset".

I don't think the clock speed should make much difference, but usually lower speed is more stable/reliable.

[etl17]

I somehow managed to brick my Nucleo STM32H755 board. Although I can connect to the second core (access port 3), I can't connect to port 0. I think I disabled the M7 core by accident through option bytes. Unfortunately, if I try to restore factory reset of the option bytes, I am getting an error "Device 0x450 not supported for factory reset operation" (while connected to the M4 core using the STM32CubeProgrammer talking to the on-board ST Link interface).

I've tried rebooting while holding BOOT0 high, but that seems to have no effect (or perhaps I don't quite understand the right sequence).

[Adam BERLINGER]

Hello @etl17 ,

This issue should be possible to solve with the STM32CubeProgrammer (v2.21, but older should work as well) and setting the BCM7 bit. I tested and used following configuration to connect to Nucleo-H755 board while Cortex-M7 is disabled.

Then I can change the option bit back in option bytes:

As you mention, the factory reset is not supported for STM32H755. Maybe there could be situations where the factory reset is not possible, or setting the option bytes to default could lead to issues.

Best regards,

Adam Berlinger