MCU works with DEBUG but not with RUN - Reset is required with RUN

[Mohammed Eshaq]

Dear STM Community,

I am working on a project that was going smoothly so far until I faced the problem mentioned above lately.

Problem/Symptoms:

When I DEBUG the code and execute it line-by-line, it works perfectly.

When I DEBUG the code and then disconnect it from the debugger to let the code run feely, it works perfectly.

When I RUN the code runs and then gets stuck as the first encounter of HAL_Delay() or any HAL function that uses a delay. After getting stuck, as soon as I reset or power cycle the board, the code runs perfectly.

Attempts to Fix the Issue:

I started having this problem lately. Even when I go back to previous builds or when I create a simple “Hello World�? application, the same behavior is observed (gets stuck on delay).

Some were suggesting to check the vector table and the reset handler (which I did), but if these were messed up, the MCU would not work upon reset either.

Others suggested that it may have to do with the NVIC SysTick priority having too low priority while it is called from a higher priority interrupt. So, I have disabled all unnecessary interrupts and kept the SysTick interrupt priority as follows.

 

MCU Option Bytes for boot address were set to the same desired address (0x 8 000 000) so that if the Boot Address line was pulled high or low it will still boot from the same address.

I am using STM32H743BIT on a custom board.

Any suggestions are highly appreciated.

[TDK]

0 is the highest priority interrupt. So set SysTick to 0 and all others above 0.

> When I RUN the code runs and then gets stuck as the first encounter of HAL_Delay() or any HAL function that uses a delay.

Attach the debugger to an already-running chip without resetting it and investigate. Should not be difficult to determine why things are stuck in the delay loop.

Also, given that you're in run mode, how are you determining/verifying this?

[MM..1]

Your description is unclean. Primary use HAL_Delay isnt never possible in callbacks of interrupts with higher level as delay, better never in isr

Secondary how you result , that stuck is in delay and not for example hardfault...

[Tesla DeLorean · Accepted solution]

Might also want to check other things.

Check proper VCAP capacitance, and voltages.

VOS settings.

LDO/SMPS settings.

Flash wait state settings.

HSE_VALUE matches board components, and PLL settings.

Issue with SysTick, check priority settings, check it's actually firing, and that vector table SCB->VTOR is what's expected and properly aligned.

[Mohammed Eshaq]

I am verifying that it is running by simply observing the output on the UART port that connected to a serial terminal.

Can elaborate more on how I can attach a debugger to an already-running chip without resetting it? I am using STM Cube IDE which is based on Eclipse.

Thanks for the help :)

[Mohammed Eshaq]

We disconnected the MCU from the other systems that it interfaces with and issue was gone.

It is definitely a hardware issue.

Thank you and every one else for the help!