QP Port to STM32 and STM32CubeIDE

Question

I need a very simple example of porting QP framework to stm32 micro controller that is based on C language and using the stm32cubeide, im very new to QP and want to learn more. I've started with blinky example of qm tool and change the bsp.c to work rightly with HAL function and port it to my blinky stm32f4 project and i have no error and program it in micro but it does not work correctly. When run to debug findout the TimeEvt (Time Event) doesn't occur and the state transition doesn't happen

Answer 1

The complete STM32Cube software is too big to fit in the QP framework installation. Therefore, the examples for STM32 that ship with the QP framework (for several STM32 NUCLEO and Discovery boards), use only parts of STM32Cube.

So, if you wish to use the complete STM32Cube software, you most likely need to adjust the initialization and interactions with the hardware through the STM32Cube API. This is really confined to the BSP (Board Support Package) in the application and has ?little to do with QP, which takes over after you initialize the board.

So in your case you must ensure that the QF_TICK_X() macro of QP is called periodically at the desired frequency. If this does not happen, the Time Events aren't serviced and they will not be posted to your active objects.

You can easily check if QF_TICK_X() is being called in a debugger by placing a breakpoint at this call. If the breakpoint is never hit, you need to configure the interrupt correctly.

One word of caution about STM32Cube and QP is to ensure that the ARM Cortex-M interrupt priorities are configured correctly. This is because QP disables interrupts only selectively and leaves the "kernel unaware" interrupts completely undisturbed. This is common practice also used in FreeRTOS, for example. Please read the pertinent section in the QP Manual:

https://www.state-machine.com/qpc/arm-cm.html#arm-cm_kernel-aware

STM32Cube is known to mess up with the interrupt priorities (e.g., of SysTick), so you need to make sure that SysTick priority is not changed to the "kernel unaware" level. If STM32Cube sets it to zero, for instance, you need to change it again to some larger priority number (lower priority in the inverted priority scheme used by Cortex-M).