Nucleo H755ZI-Q: 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

[Daniel_Ismail]

However, when I use the MXcube to generate the code for the BSP or Nucleo-H755 board rather the chip, everything works fine. The issue is that we can't proceed with the Nucleo or BSP because we are designing a custom board that doesn't match the Nucleo board.

In our case, I have noticed that there's no delay in the Reset_Handler in the BSP code, so I don't think the issue is related to Reset_Handler. What could be causing the problem in our setup?

[Tesla DeLorean]

Well perhaps you're going to need to delta/diff the initialization code to understand what's different in the working vs non-working situations.

Use bisection methods to add/remove different parts of the code so you can focus in on the specific area that's the problem. The H7 can run from the 64 MHz HSI and bus settings it starts with, you don't need to change the clocks, bus or PLL settings for the part to continue running.

[SofLit · Accepted solution]

Hello @Daniel_Ismail ,

The issue is due to a limitation in the new CubeMx version described in this thread. Refer to the solution.

Two defines of the power configs are generated by CubeMx for the same project:

You need to remove the define USE_PWR_LDO_SUPPLY from the project preprocessor and need to recover your board from the lock situation. Refer to the thread mentioned previously.

[Daniel_Ismail]

Thanks a bunch @SofLit !That solution worked perfectly! I had spent days trying to resolve this issue, and this approach finally fixed it as expected. I'll also add the spinning as suggested by @Tesla DeLorean  delay to ensure the setup is even more robust. By the way, will the upcoming version include a fix for this issue?

[SofLit]

---

@Daniel_Ismail wrote:

 By the way, will the upcoming version include a fix for this issue?

---

I don't have this visibility but most probably in the next release.