cancel
Showing results for 
Search instead for 
Did you mean: 

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

Mohammed Eshaq
Associate III

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.

0693W00000KcmyFQAR.png 

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.

1 ACCEPTED SOLUTION

Accepted Solutions

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

5 REPLIES 5
TDK
Guru

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?

If you feel a post has answered your question, please click "Accept as Solution".
MM..1
Chief II

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

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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 :)

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!