Showing results for 
Search instead for 
Did you mean: 

HAL_Delay function does not return

Associate III

I have a bare metal board with an STM32H723ZGT6.

I can connect and program the device.

Initially I tried to use the HAL_Delay function but I found it hung the program never returning.

This I determined by illuminating an LED on each side of the function, the first lights the second stays off.

I then switched the HAL_Delay function for a delay in code so I can create the blinky LED in a coded delay.

I then tried to implement a separate simple timer and that does not seem to function either trying to toggle an LED in the handler - no joy.

I have ensured interrupts are enabled using __enable_irq and I also changed the timerbase priority from 15 to 0 in the NVIC setting.

I am puzzled as to why interrupts do not seem to be occuring.

Open to any suggestions on this as I really need a simple timer I can use.


If systicks are not occurring, there are a limited number of reasons why. In rough order of probability:

  • You are in a higher or equal priority interrupt. Systick will be unable to pre-empt it. 
  • Interrupts are globally disabled.
  • Systick are not initialized or the interrupt is not not enabled.

Instead of using LEDs to debug, consider debugging the code and stepping through to identify what is and is not happening. If interrupts are enabled and want to fire, the VECTPENDING field will be populated in SCB->ICSR. If that field is zero, they're not trying to fire.

There is also the possibility of another code bug or a misunderstanding of what the code is doing.

If you feel a post has answered your question, please click "Accept as Solution".
Associate III

I removed all code and just implemented the HAL_Delay(1000) function and stepped through the code.

The following function I can see the uwTick does not run so I have no interrupt.

* @brief Provides a tick value in millisecond.
* @note This function is declared as __weak to be overwritten in case of other
* implementations in user file.
* @retval tick value
__weak uint32_t HAL_GetTick(void)
return uwTick;

I put breakpoints on the interrupt handlers a few at a time to see if any higher level interrupt like NMI was firing.

I then as your suggestion inspected uint32_t x = SCB->ICSR; returns 0 so nothing is pending so interrupts are not even wanting to fire? That seems strange to me.

I am new to this platform so I am struggling on this.

NMI might fire if you touch unprogrammed FLASH memory, it's where the ECC fault goes.

Check that your SystemInit() function sets SCB->VTOR to your vector table correctly.

Have HardFault_Handler(), Error_Handler() and NMI_Handler(), etc output useful and actionable data to aid in finding the cause / source of failures.

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

I took the advice on the handlers I turn an LED on if they fault.

I found the SystemInit() function and could see where the SCB->VTOR is set.

You will probably know the default value for SCB->VTOR because I read a hex value as being 0x1ff09800 which from what I can gather I think it is wrong.


Go into your system_stm32h7xx.c file an uncomment the following line:

If you feel a post has answered your question, please click "Accept as Solution".
Associate III

Thank you read out SCB->VTOR as an uint32_t and looked right 0x80000000.

I understand why it is a bare metal project and I need to initialize this whereas many examples will do this for you.

Thank you I have a running system, interrupts and flashing LED's allows me to really explore the capabilities.

> 0x80000000

Guessing this is a typo and you meant 0x08000000. If not, 0x80000000 is not a valid address.

If you feel a post has answered your question, please click "Accept as Solution".
Associate III

Yes sorry ... system works fine and thank you so much for your help.