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  @mƎALLEm 

[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

 

[mƎALLEm]

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 @mƎALLEm !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?

[mƎALLEm]

---

@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.

[mƎALLEm]

Issue fixed in CubeMx 6.14.0 (already available on ST website)