I am working on UART communication between two STM32 development boards: an STM32H7B3I-EVAL (STM32H7B3LI MCU) configured as the master and an STM32H573I-DK (STM32H573II MCU) configured as the slave.
When HAL_Delay() is not added in the master application, the master continuously transmits data over UART, and the slave receives the data continuously without any issues.
When HAL_Delay() is added after the UART transmission, the master transmits the data only once and then stops.
During debugging, the application is found to be stuck inside HAL_Delay().
The attached screenshot shows that HAL_GetTick() always returns 0, and the global tick counter uwTick also remains 0 throughout execution.
Since the HAL tick never increments, HAL_Delay() never completes and the application remains blocked.
If execution is resumed from the debugger, the application eventually enters Error_Handler().
I have attached the debugger screenshot showing the values of HAL_GetTick(), uwTick, and the SysTick registers for reference.
I would appreciate any guidance on how to ensure the HAL tick is incrementing correctly and what could be preventing the HAL time base from running on this setup.
Could you please share your code? That will help us assist you more effectively.
In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Saket_Om
In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Saket_Om
> The “classical” error: SysTick IRQ priority is not highest.
> Make sure that all other IRQs have a lower priority.
I don’t think that is the issue.
Exactly WHAT interrupt would be preventing the SysTick IRQ from being serviced? This person is using polled UART transmit, and in the code I don’t see any other interrupt handlers aside from the standard fault handlers and the SysTick handler.
I haven’t looked at the IOC file, but @Saket_Om is on the right track.
If execution is resumed from the debugger, the application eventually enters Error_Handler().
If it’s stuck in HAL_Delay waiting for the ticks to increase, it can not jump into Error_Handler. There is no code path that reaches there from the loop. Examine the code yourself and verify.
The stack trace when it hits Error_Handler would be useful. No doubt there is more going on that what has been presented.
The screenshot is helpful but note that expressions are not evaluated while the code is running. The code is running in the screenshot.
"If you feel a post has answered your question, please click ""Accept as Solution""."
The issue is most likely with the HAL tick not running. Check that HAL_Init() is called before UART initialization and that SysTick_Handler() contains HAL_IncTick();.
Put a breakpoint inside SysTick_Handler() to confirm it is being triggered. If it is not, check your clock configuration, interrupt settings, and whether any custom code is disabling or replacing SysTick. On STM32H7, the HAL tick source can also be moved to another timer, so verify that the selected time base is correctly configured.
