STM32H745XI – HAL_Init() hangs in HAL_Delay() during debug

[Srikanth1]

 

Hi,

I am working on a custom board using STM32H745XI MCU.

I am facing an issue on one particular board.

The same source code works correctly on our other boards with the same MCU and hardware. On the problematic board:

• The firmware can be programmed successfully using STM32CubeProgrammer.

• After programming, the firmware runs normally.

• But when I debug the same firmware from STM32CubeIDE using ST-LINK, execution reaches Reset_Handler and then main().

• HAL_Init() is entered, but it does not return.

• After debugging HAL_Init(), I found that execution is actually hanging at:

HAL_Delay(1000);

inside HAL_Init().

The relevant flow is:

Reset_Handler
      ↓
    main()
      ↓
  HAL_Init()
      ↓
 HAL_InitTick()
      ↓
 HAL_MspInit()
      ↓
 HAL_Delay(1000)
      ↓
    HANG
      ↓
SystemClock_Config()   ← never reached

My understanding of the problem

HAL_Delay() depends on the HAL tick counter (uwTick) being incremented periodically by the SysTick interrupt.

Normally the flow should be:

SysTick interrupt
      ↓
SysTick_Handler()
      ↓
HAL_IncTick()
      ↓
uwTick++
      ↓
HAL_Delay() detects elapsed time
      ↓
HAL_Delay(1000) returns

If the SysTick interrupt is not occurring, or HAL_IncTick() is not being executed, uwTick will not increase and HAL_Delay(1000) can remain in its waiting loop indefinitely.

This is happening before SystemClock_Config(), so the system is still using the default clock configuration after reset.

I am trying to understand why this happens only during debugging on this particular board, while the same firmware runs correctly when programmed using CubeProgrammer and also works correctly on other identical boards.

Could this be related to:

• SysTick interrupt not being generated during debug

• ST-LINK/debug reset behavior

• Interrupt configuration or priority

• Cortex-M7 startup/debug state

• Option Bytes or boot configuration

• Any STM32H745-specific debug behavior

Any suggestions on what could cause HAL_Delay() to hang at this stage would be appreciated.

[AScha.3]

Hi,

Seems your problem is related to the clock system.

So first check soldering of the crystals or oscillator, HSE and LSE, then check them running/working with a scope.

Maybe make a new small project, with MCO set, to see the internal clocks and check them with a scope.

Or just using the internal HSI/LSI clock to see, is CPU running now fine.

[Srikanth1]

Thank you for the suggestion. I will check the HSE/LSE and clock signals as suggested.

However, I would like to clarify one important point about my issue.

The same firmware .bin runs correctly on the problematic board when it is programmed using STM32CubeProgrammer and the board is allowed to run normally. The issue occurs only when I launch the same firmware through STM32CubeIDE using ST-LINK debugging.

The source code and binary are the same in both cases. On the problematic board:

Normal execution:
Reset_Handler → main() → HAL_Init() → ... works correctly.

Debug execution:
Reset_Handler → main() → HAL_Init() → HAL_InitTick() → HAL_MspInit() → HAL_Delay(1000) hangs.

This makes me suspect that the clock hardware itself is probably functional, because the same programmed binary executes correctly without the debugger.

My question is therefore: could the difference be caused by the ST-LINK debug reset/attach sequence, Cortex-M7 debug state, SysTick behavior during debug, DBGMCU configuration, or the way the debugger handles reset/halt before SystemClock_Config() is reached?

Is there a specific STM32H745 debug/reset setting or register that you recommend checking in this situation?

[AScha.3]

Oooo...this is different now.

>The same firmware .bin runs correctly on the problematic board when it is programmed using STM32CubeProgrammer and the board is allowed to run normally.

So there should be no hardware problem on the board.

I see 3 options :

1. if board is for life critical equipment : throw it to recycling bin.
2. if board expensive : replace cpu and test it.
3. if board is for any machine : test it for working fine and let it do its job.
4. if you  have a lot of free time and curious about, what this strange behaviour could mean…

First : what is in IDE-debug, when restart program?  + if stop debug, reset , run...Ok or not ?

 

Then try with CubeProgrammer: flash, disconnect; run, test it (ok ?), then connect in hot plug mode + software reset, check its running normal; (hot plug connects without stopping the cpu);

then halt, reset, run - check again, halt , still in normal execution or hangs ?

Try to find out: has this cpu any strange defect or not ...

 

[EXUE.2]

which reset option were you selected? software reset or hardware reset? you can try it with different reset option. For this issue, I guess it is caused by internal HSI clock, maybe the MCU of this board is not stable.

[Srikanth1]

Thank you for the suggestion.

Regarding the HSI clock, I would like to clarify one point. The same MCU/board and the exact same .bin file runs correctly when programmed and started normally without the debugger. The problem occurs only when I start a debug session through STM32CubeIDE/ST-LINK.

The hang occurs very early, inside HAL_Init() at HAL_Delay(), before my SystemClock_Config() is called.

So if the MCU/HSI itself were unstable, I would expect the standalone execution to show the same problem as well. Since standalone execution is working reliably.

[Saket_Om]

Hello ​@Srikanth1 

Did you try setting the SysTick interrupt to a higher priority (that is, a lower numerical value)?

[Srikanth1]

Hello, thank you for the suggestion.

I have not tried increasing the SysTick interrupt priority yet. Currently, I am using the default SysTick priority configuration.

I will try setting the SysTick interrupt to a higher priority (lower numerical value) and check whether HAL_Delay() still hangs when starting the debug session.

One observation that may be important is that the exact same binary runs correctly when the board is programmed and allowed to run normally without the debugger. The problem occurs only when running through STM32CubeIDE/ST-LINK debugging.

Since the hang occurs inside HAL_Delay(), I will also check whether the SysTick interrupt is actually firing and whether uwTick is incrementing during the debug session.

I will test this and update the result.

[Pavel A.]

It looks that your program runs after some "bootlooader”, which sets up the interrupt vectors address and maybe more. When you debug the program with CubeIDE debugger, it can skip the bootloader so your program starts in unexpected environment.

See the CubeIDE user guide to tweak the debugger so that the bootloader always executes first.

 

[Srikanth1]

Hello, thank you for the suggestion.

In our current setup, we are not using any bootloader. The application is programmed directly into the MCU and starts directly after reset.

Also, the same application code/binary is working correctly on our other STM32H745 boards.

On the problematic board, the same binary also runs correctly when the board is programmed and allowed to run normally without the debugger. The issue occurs only when starting a debug session using STM32CubeIDE/ST-LINK.

Therefore, I don't think a bootloader being skipped is involved in this case.

The debug execution hangs very early in HAL_Init(), specifically at HAL_Delay(), before our SystemClock_Config() is called.

 

If you have any suggestions specifically related to the STM32H745 debug/reset sequence or why HAL_Delay() could behave differently only when connected to the debugger, that would be very helpful.

[TDK]

Show your code. Why is there a HAL_Delay(1000) in MspInit? That is atypical, so what else is in there? The AI-infused questions and responses make it difficult to see what the actual problem is here.

[Srikanth1]

Hello, thanks for pointing that out.

Here is my HAL_Init() function. As you can see, HAL_Delay(1000) is not inside HAL_MspInit(). It is called after HAL_MspInit() returns.

I added this HAL_Delay(1000) to check the behavior of the SysTick/time base during the early initialization.

The important point is that this exact same code and binary works correctly on another STM32H745 board, and it also runs correctly on the problematic board when it is run normally without the debugger.

The problem occurs only when I start the application through the STM32CubeIDE debugger on this particular board. The debugger stops/hangs at:

HAL_Delay(1000);

Here is the complete HAL_Init() function:

HAL_StatusTypeDef HAL_Init(void)
{

uint32_t common_system_clock;

#if defined(DUAL_CORE) && defined(CORE_CM4)
   /* Configure Cortex-M4 Instruction cache through ART accelerator */
   __HAL_RCC_ART_CLK_ENABLE();                   /* Enable the Cortex-M4 ART Clock */
   __HAL_ART_CONFIG_BASE_ADDRESS(0x08100000UL);  /* Configure the Cortex-M4 ART Base address to the Flash Bank 2 : */
   __HAL_ART_ENABLE();                           /* Enable the Cortex-M4 ART */
#endif /* DUAL_CORE &&  CORE_CM4 */

  /* Set Interrupt Group Priority */
  HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);

  /* Update the SystemCoreClock global variable */
#if defined(RCC_D1CFGR_D1CPRE)
  common_system_clock = HAL_RCC_GetSysClockFreq() >> ((D1CorePrescTable[(RCC->D1CFGR & RCC_D1CFGR_D1CPRE)>> RCC_D1CFGR_D1CPRE_Pos]) & 0x1FU);
#else
  common_system_clock = HAL_RCC_GetSysClockFreq() >> ((D1CorePrescTable[(RCC->CDCFGR1 & RCC_CDCFGR1_CDCPRE)>> RCC_CDCFGR1_CDCPRE_Pos]) & 0x1FU);
#endif

  /* Update the SystemD2Clock global variable */
#if defined(RCC_D1CFGR_HPRE)
  SystemD2Clock = (common_system_clock >> ((D1CorePrescTable[(RCC->D1CFGR & RCC_D1CFGR_HPRE)>> RCC_D1CFGR_HPRE_Pos]) & 0x1FU));
#else
  SystemD2Clock = (common_system_clock >> ((D1CorePrescTable[(RCC->CDCFGR1 & RCC_CDCFGR1_HPRE)>> RCC_CDCFGR1_HPRE_Pos]) & 0x1FU));
#endif

#if defined(DUAL_CORE) && defined(CORE_CM4)
  SystemCoreClock = SystemD2Clock;
#else
  SystemCoreClock = common_system_clock;
#endif /* DUAL_CORE && CORE_CM4 */

  /* Use systick as time base source and configure 1ms tick (default clock after Reset is HSI) */
  if(HAL_InitTick(TICK_INT_PRIORITY) != HAL_OK)
  {
    return HAL_ERROR;
  }

  /* Init the low level hardware */
  HAL_MspInit();
  HAL_Delay(1000);
  /* Return function status */
  return HAL_OK;
}

So I am trying to understand why the same code behaves differently only during a debug session.

 

[Pavel A.]

 - Are all these STM32H745 of the same stepping?

 - Any difference in option bytes?