Persistent Issue with Nucleo H755ZI-Q Configuration: The interface firmware FAILED to reset/halt the target MCU

[Daniel_Ismail]

I am facing a persistent issue with the Nucleo H755ZI-Q board that is driving me crazy! 

The issue I am having is : 

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.0.202409170845\tools\bin\STM32_Programmer_CLI.exe

Error in STM32CubeProgrammer

Here's the setup and steps I've followed:

1. Chip Configuration:

   • Selected STM32H755ZIT6 in STM32CubeMX.
   • Disabled HSE and enabled LSE with a crystal resonator.
   • Set M7 clock to 400 MHz and M4 clock to 200 MHz.
   • Power settings:
     • Supply source: PWR_DIRECT_SMPS_SUPPLY.
     • Power regulator voltage scale: 1.

1. Peripheral Configuration:

   • I2C1: PB8, PB9.
   • USART1: PB14, PB15.
   • USART2: PA2, PA3.
   • Configured GPIO for onboard LEDs and user switch.

2. Debug Configuration:

• Followed the guidelines from the video
  https://www.youtube.com/watch?v=jI1k6p-fduE&t=770s

And, Beside the MCU not able to finding it's target, after restarting  the device I receive this, 

The interface firmware FAILED to reset/halt the target MCU

I’ve rechecked the configurations multiple times and followed the guidelines for debugging and clock setup. Despite all efforts, the issue persists. 

My Steps to Troubleshoot So Far:

• Verified all clock and peripheral settings in CubeMX.
• Double-checked debug settings.
• Ensured all pins are correctly configured.
• Re-Update STlink V3 [HSI-8Mhz] 
• Deleted the H7 package and re-downloaded it
• Uninstalled CubeIDE and re-installed it. 

I've lost the counts how many times I have factory reset my MCU. I’d greatly appreciate any guidance or solutions to resolve this issue. Could it be related to the power supply settings, debug interface, or something else entirely?

@TDK  @Tesla DeLorean @Sara BEN HADJ YAHYA  @SofLit 

[Tesla DeLorean]

Generally it relates to SMPS/VOS settings, but you indicate those are set suitably.

Other things could be how the cores start, or you've got something that interferes with PA13/PA14 debug pins. Make sure SWD/JTAG has not been disabled/suppressed via settings.

I'd probably solder a right-angle jumper on the BT0/VDD pins of the NUCLEO pin header, and perhaps add a spinning delay in the Reset_Handler() to permit the core to be wrestled by the ST-LINK.

[Daniel_Ismail]

The voltage settings are suitably configured, and I haven’t made any changes in MXCube beyond what I’ve already mentioned in my post. To clarify, I haven’t written any additional code either, so nothing has been done that would intentionally affect PA13/PA14.

Regarding the suggestion to solder a jumper on BT0/VDD, could you please explain the purpose of this modification? I’d also appreciate more details on how adding a spinning delay in the Reset_Handler() would help and how to implement it effectively.

Thanks in advance for your guidance!

[Tesla DeLorean]

The BT0 jumper allows for two things, it enters ROM System Loader rather than your code, which provides a safe harbour to erase your broken code running in FLASH. Also if the board is bricked by using LDO rather than SMPS you can power cycle the board completely twice with the jumper on to clear the issue.

With the delay in Reset_Handler you are buying time allowing the debug to wrestle control before your code gets to run fully and change pins, etc.

Reset_Handler   PROC
                EXPORT  Reset_Handler             [WEAK]
                IMPORT  SystemInit
                IMPORT  __main

        movs    r0, #0
delay   subs    r0, r0, #1
        bne.n   delay

                LDR     SP, =__initial_sp
				
                LDR     R0, =SystemInit
                BLX     R0
				
                LDR     R0, =__main
                BX      R0
				
                ENDP