SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world.
And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download two short videos (registration required) highlighting:

System Workbench for STM32

STM32F4 HAL Driver Callbacks


I am developing for an STM32F4. I’m using STM32CubeMX and System Workbench for STM32. I’m using FreeRTOS. I would like to know how I should, and should not, be using the STM32F4 HAL Driver callbacks.

As an example, I’m using HAL_CAN_RxCpltCallback. Within this call back, I decode and validate the CAN frame, and then generate a number of different events (i.e. using xQueueSendFromISR). Or in some cases, I populate a CAN frame in response, and send it within the callback. Currently I have 300 lines of code in this specific callback.

Ideally, I would make the callback easier to read, by calling out to additional functions; i.e. if the CAN frame/message is a request for date, then call handleRequestForData(), and so on.

However, I can see that HAL_CAN_RxCpltCallback is called from HAL_CAN_IRQHandler. So I take it that HAL_CAN_RxCpltCallback is also an IRQ. And its my understanding that I should keep all IRQ’s short, and not to call out to other functions (due to stack size limitations).

So my question is, should I minimize the amount of code in my callbacks. And in this case, simply push the CAN frame into another queue for another task to handle it?

Thanks, Matt.


Hi Matt,

Yes, the HAL CAN Callback is called in an ISR context and should

  1. be kept short
  2. only call fromISR FreeRTOS functions

Generating various events from the ISR (using xQueueSendFromISR) is fine but calling back the HAL CAN driver to send data is probably too much (and may even be a source of race conditions...) so this should be defered to some (possibly high priority) task.

Bernard (Ac6)