AnsweredAssumed Answered

calling hal_delay inside callback (ISR)

Question asked by thy on May 12, 2015
Latest reply on May 18, 2015 by childress.steve
Hi, I'm struggling with this on stm32f429 discovery board with arm cortex M4:

I have a reception task via UART which receive a character per time and put it in a circular buffer cbuff. When some conditions on the received character (i.e. \r has been received) and on the buffer (i.e. cbuff is full) this is printed over a terminal. For some reasons in the function which prints cbuff over the terminal I need to have a delay, so I call HAL_Delay(10). I also use freeRTOS and the calls cascade is


where cb_push_back() is the function that manages cbuf. Within cb_push_back() I call HAL_Delay(10) and everything get stucked. Particularly, in turn HAL_Delay() calls HAL_GetTick() within the while loop (see stm32f4xx_hal.c for reference) and the latter never returns (uwTick is never increased I think).

Clearly, at least this is what I guess, it is matter of interrupts priorities. And here comes my troubles: according to and Google, SysTick priority must be the lowest possible (in my case 15) and my code fits this requirement. Further, according to UM1725 "In the default implementation, SysTick timer is the source of
time base. It is used to generate interrupts at regular time
intervals. Care must be taken if HAL_Delay() is called from a
peripheral ISR process, The the SysTick interrupt must have
higher priority (numerically lower) than the peripheral
interrupt. Otherwise the caller ISR process will be blocked.
The function is declared as __weak to be overwritten in case
of other implementation in user file.". So according to my particular case it looks like there is no way I can make it working since I can, at the best, have the UART Rx ISR priority equal to that of SysTick.
Am I right or am I missing something? Should I use timers instead?

Thank you and regards.