on - edited on by
Laurids_PETERSE
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:
- Plug the board to the power supply, while the reset button is being held low (or NRST pin in general).
- Keep the reset button low.
- Connect via STM32CubeProgrammer. When the program starts connecting, release the reset button. Although this requires quite precise timing, it should be easy to achieve.
- Perform mass erase.
- Make sure that you fixed the power-supply configuration in your project.
Solution 2:
- 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.
- Keep the BOOT0 button high.
- 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).
- Perform a mass erase.
- 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.
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
Hello Sir,
I am facing an issue with the STM32H755ZIQ MCU on my custom board. I would appreciate your help in identifying the root cause.
After erasing the MCU flash, I am observing inconsistent behavior with ST-LINK connection depending on VCC voltage.
Observed Behavior
First, I erased the MCU memory. After that, I tried to upload or debug the program using ST-LINK while supplying 3 V, but I got the same CM7 error that I mentioned earlier.
Then I tried flashing the MCU by supplying 2 V VCC, and at that time ST-LINK did not show any error and the flash programming worked.
After programming, I supplied 3 V again, and the LED started blinking correctly.
However, I don’t understand why ST-LINK is not able to detect or work with the target when VCC is 3 V, but it works fine when VCC is 2 V.
Before erasing the memory, ST-LINK was not detecting the target at 3 V. After erasing the memory, it is detecting the target.
STMicroelectronics ST-LINK GDB server. Version 7.11.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.20.0
-------------------------------------------------------------------
Log output file: C:\Users\kavya\AppData\Local\Temp\STM32CubeProgrammer_a18056.log
ST-Link Server is running on port : 7184
ST-LINK SN : 34FF6B064154343122480157
ST-LINK FW : V2J46S7
Board : --
Voltage : 2.70V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x450
Revision ID : Rev V
Device name : STM32H7xx
Flash size : 2 MBytes
Device type : MCU
Device CPU : Cortex-M7/M4
BL Version : 0x92
Opening and parsing file: ST-LINK_GDB_server_a18056.srec
Memory Programming ...
File : ST-LINK_GDB_server_a18056.srec
Size : 3.14 KB
Address : 0x08100000
Erasing memory corresponding to segment 0:
Erasing internal memory sector 8
Download in Progress:
File download complete
Time elapsed during download operation: 00:00:01.126
Verifying...
Time elapsed during verifying operation: 00:00:00.037
Download verified successfully
Target no device found
Failed to restart ST-LINK connection
Failed to read DAP register for AP 0
Failed to read ROM table via AP 0
Failed to reinitialize device
-------------------------------------------------------------------
STM32CubeProgrammer v2.20.0
-------------------------------------------------------------------
Log output file: C:\Users\kavya\AppData\Local\Temp\STM32CubeProgrammer_a18056.log
ST-Link Server is running on port : 7184
ST-LINK SN : 34FF6B064154343122480157
ST-LINK FW : V2J46S7
Board : --
Voltage : 2.79V
Error: Unable to get core ID
Error: No STM32 target found! If your product embeds Debug Authentication, please perform a discovery using Debug Authentication
Encountered Error when opening C:\ST\STM32CubeIDE_1.17.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.2.200.202503041107\tools\bin\STM32_Programmer_CLI.exe
Error in STM32CubeProgrammer
Shutting down...
Exit. this is error i am getting
And this is my code now after erase
void SystemClock_Config(void)
{
RCC_OscInitTypeDef RCC_OscInitStruct = {0};
RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
/** Supply configuration update enable
*/
HAL_PWREx_ConfigSupply(PWR_DIRECT_SMPS_SUPPLY);
/** Configure the main internal regulator output voltage
*/
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}
/** Initializes the RCC Oscillators according to the specified parameters
* in the RCC_OscInitTypeDef structure.
*/
/* Enable HSE Oscillator and activate PLL with HSE as source */
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
RCC_OscInitStruct.HSIState = RCC_HSI_DIV1;
RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;
RCC_OscInitStruct.PLL.PLLM = 4;
RCC_OscInitStruct.PLL.PLLN = 10;
RCC_OscInitStruct.PLL.PLLP = 2;
RCC_OscInitStruct.PLL.PLLQ = 128;
RCC_OscInitStruct.PLL.PLLR = 2;
RCC_OscInitStruct.PLL.PLLRGE = RCC_PLL1VCIRANGE_3;
RCC_OscInitStruct.PLL.PLLVCOSEL = RCC_PLL1VCOMEDIUM;
RCC_OscInitStruct.PLL.PLLFRACN = 0;
if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
{
Error_Handler();
}
/** Initializes the CPU, AHB and APB buses clocks
*/
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2
|RCC_CLOCKTYPE_D3PCLK1|RCC_CLOCKTYPE_D1PCLK1;
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_HSI;
RCC_ClkInitStruct.SYSCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.AHBCLKDivider = RCC_HCLK_DIV1;
RCC_ClkInitStruct.APB3CLKDivider = RCC_APB3_DIV1;
RCC_ClkInitStruct.APB1CLKDivider = RCC_APB1_DIV2;
RCC_ClkInitStruct.APB2CLKDivider = RCC_APB2_DIV1;
RCC_ClkInitStruct.APB4CLKDivider = RCC_APB4_DIV1;
if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1) != HAL_OK)
{
Error_Handler();
}
}
this is my customized board board schematic
@Adam BERLINGER
@Tesla DeLorean
@Andrew Neil
