How to enter and exit low-power mode with CMSIS RTOS API.
This application creates two threads.
+ An Rx thread that blocks on a queue to wait for data, blinking LED each
time data is received (turning it on and then off again) before returning
to block on the queue once more.
+ A Tx thread that repeatedly enters the Blocked state for 500ms.
On exiting the blocked state, the Tx thread sends a value through the queue
to the Rx thread (causing the Rx thread to exit the blocked state and blink
the LED).
Blocking for a finite period allows the kernel to stop the tick interrupt
and place the STM32 into sleep mode - the lowest power mode possible
that allows the CPU registers and RAM to retain their state.
In this application, not used GPIOs are configured to analog. This helps reduce
the power consumption of the device.
Observed behaviour:
Every 500ms the MCU will come out of the low power state to turn the LED1 on,
then return to the low power state for 20ms before leaving the low power
state again to turn the LED1 off. This will be observed as a fast blinking
on the LED1.
The RTOS tick is suppressed while the MCU is in its low power state.
@note Care must be taken when using HAL_Delay(), this function provides accurate delay (in milliseconds)
based on variable incremented in HAL time base ISR. This implies that if HAL_Delay() is called from
a peripheral ISR process, then the HAL time base interrupt must have higher priority (numerically lower)
than the peripheral interrupt. Otherwise the caller ISR process will be blocked.
To change the HAL time base interrupt priority you have to use HAL_NVIC_SetPriority() function.
@note The application needs to ensure that the HAL time base is always set to 1 millisecond to have correct
HAL operation.
@note The FreeRTOS heap size configTOTAL_HEAP_SIZE defined in FreeRTOSConfig.h is set according to the OS resources memory requirements of the application with +10% margin and rounded to the upper Kbyte boundary.
For more details about FreeRTOS implementation on STM32Cube, please refer to UM1722 "Developing Applications
on STM32Cube with RTOS".
@note The connection of the LCD reset pin to a dedicated GPIO PK7 instead of the STM32F469 NRST pin may cause residual display on LCD with applications/examples that do not require display.
The LCD clear can be ensured by hardware through the board's power off/power on or by software calling the BSP_LCD_Reset() function.
