Hello everyone,
return to the issue of problems that can arise using the HAL_Delay (), within the Interrupt service functions in projects for embedded systems without RTOS.
Briefly: the HAL_Delay (), uses the interrupts thrown every mSec by the system timer SysTick; these interrupts increment a counter and the HAL_Delay () waits within a while for the counter value to reach the desired value.
But in the projects I made in the Cube environment, the SysTick is assigned by the development environment, in the HAL_Init () function, a priority of 15 (the lowest).
You can see this both from the MX environment and from the code.
Obviously an IRQ service function with higher priority (<15) can never be interrupted, and when using the HAL_Delay (), the Systick counter cannot be counted and the HAL_Delay() function is blocked; the system stops advancing.
I use a micro STM32F401 and as some external peripherals I use, they often need small delays , also in some interrupt situation (I think it happened to you too)
I tried to:
a) change the priority of the service function on SystTick interruption to a very high value (1 and sometimes 0),
b) declare ALL the interrupts used and controlled by me, with lower authority (2,3, ..).
The system works, for the tests I have been able to do. But some questions remain:
a) why does the CUBE system by default bring the priority of the SysTick to the minimum value? it was easily foreseeable that problems would arise.
b) what problems will I encounter on systems with more complex code? (I don't think I'm using RTOS).
Thank you.
Luciano
