Skip to main content
A
Adam BERLINGER
ST Employee
October 17, 2019

Unable to connect to STM32H7 devices

  • October 17, 2019
  • 13 replies
  • 26327 views

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.
68.png
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.

      This topic has been closed for replies.

      13 replies

      Show previous replies
      K
      kavyamm
      Graduate
      January 6, 2026

       

       

       

      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

      kavyamm_0-1767702451420.png

      @Adam BERLINGER 
      @Tesla DeLorean
      @Andrew Neil

       



      K
      kavyamm
      Graduate
      January 6, 2026

      .

      A
      Adam BERLINGERAuthor
      ST Employee
      January 7, 2026

      Hello @kavyamm ,

      from the first log of the CubePogrammer, it looks like the programming went ok and the error appears after. Maybe this could be related to power supply configuration during startup of the firmware. In latest CubeFW/CubeMX, this is done as well in the system_stm32h7xx.c (or similar) startup file in function ExitRun0Mode. This is based on global macro definition, but it might be possible that this is not correctly generate by CubeMX.

      Regarding the schematic, the BOOT0 pin needs to be connected somewhere. Leaving it floating will lead to non-deterministic behavior, since HW can detect 0 or 1 at random during startup. However, I doubt this is the root cause, since entering bootloader shouldn't affect the debug capability.

      In the power supply I don't see any major issues. I think the C31/C32 should be 100nF in SMPS configuration. In any case, I would recommend checking AN4938: https://www.st.com/resource/en/application_note/an4938-getting-started-with-stm32h74xig-and-stm32h75xig-mcu-hardware-development-stmicroelectronics.pdf

      Maybe it would be best to create support ticket at ST support: https://ols.st.com/s/

      Best regards,

      Adam Berlinger

      Terms & ConditionsAccessibility statement