Introduction

The demo application documented on this page demonstrates how the FreeRTOS
tick suppression (tickless idle mode)
features can be used to minimise the power consumption of an
application running on a STM32L152 ARM Cortex-M3 microcontroller
from ST. The STM32L is
designed specifically for use in applications that require extremely low power
consumption.

The official FreeRTOS zip file download contains the source files for all the RTOS
ports, and all the demo applications, only a few of which are needed by this
project.
See the Source Code Organization
section for a description of the downloaded files and information on creating a
new project.

The IAR project file for the STM32L152 demo application is called
RTOSDemo.eww, and is located in the FreeRTOS/Demo/CORTEX_STM32L152_Discovery_IAR
directory.

Hardware set up

The demo uses the LED built onto the STM32L Discovery Board and no hardware setup is required.

Functionality

The single project file can be configured to create either a low power demo, or
a standard RTOS demo. The configCREATE_LOW_POWER_DEMO constant is used to switch between
the two. configCREATE_LOW_POWER_DEMO is defined at the top of FreeRTOSConfig.h
(FreeRTOS/Demo/CORTEX_STM32L152_Discovery_IAR/include/FreeRTOSConfig.h, and included in
the IAR project).

Functionality with configCREATE_LOW_POWER_DEMO set to 1

If configCREATE_LOW_POWER_DEMO is set to 1 then main() calls main_low_power().
main_low_power() is implemented in the main_low_power.c C source file.

Low power modes are entered when the RTOS tick is stopped (suppressed).
Deeper low power modes have longer wake up periods that lighter low power
modes, and power is also used simply entering and especially exiting the low
power modes. How the low power modes are used therefore requires careful
consideration to ensure power consumption is truly minimised and that the
embedded device meets its real time requirements.

The low power demo is configured to
select between four different modes depending on the anticipated idle period.
Note the time thresholds used to decide which low power mode to enter are
purely for convenience of demonstration, and are not intended to represent
optimal values for any particular application.

The STM32L specific part of the tickless operation is implemented in the
STM32L_low_power_tick_management.c C source file. Tick interrupts are generated from the TIM2
peripheral so a slow input clock can be used and the timer can be configured to
carry on running when the STM32 is in the lighter of the used low power modes.

Implementation:

Two tasks are created, an Rx task and a Tx task. A queue is created to
pass a message from the Tx task to the Rx task.

The Rx task blocks on a queue to wait for data, blipping an LED each time
data is received (turning it on and then off again) before returning to
block on the queue once more.

The Tx task repeatedly blocks on an attempt to obtain a semaphore, and
unblocks if either the semaphore is received or its block time expires.
After leaving the blocked state the Tx task uses the queue to send a
value to the Rx task, which in turn causes the Rx task to exit the
Blocked state and blip the LED. The rate at which the LED is seen to blip
is therefore dependent on the block time.

The Tx task's block time is changed by the interrupt service routine that
executes when the USER button is pressed. The low power mode entered
depends on the block time (as described in the Observed Behaviour section
below). Four block times are used: short, medium, long and infinite.

Low Power Behaviour:

The block time used by the Tx task is initialised to its 'short' value,
so when the Tx task blocks on the semaphore it times-out quickly, resulting
in the LED toggling rapidly. The timeout period is less than the value of
configEXPECTED_IDLE_TIME_BEFORE_SLEEP (set in FreeRTOSConfig.h), so the
initial state does not suppress the tick interrupt or enter a low power mode.

When the button is pressed the block time used by the Tx task is increased
to its 'medium' value. The longer block time results in a slowing of the
rate at which the LED toggles. The time the Tx task spends in the blocked
state is now greater than configEXPECTED_IDLE_TIME_BEFORE_SLEEP, so the tick
is suppressed. The MCU is placed into the 'Sleep' low power state while the
tick is suppressed.

When the button is pressed again the block time used by the Tx task is
increased to its 'long' value, so the rate at which the LED is observed to
blip gets even slow. When the 'long' block time is used the MCU is placed
into its 'Low Power Sleep' low power state.

The next time the button is pressed the block time used by the Tx task is
set to infinite, so the Tx task does not time out when it attempts to obtain
the semaphore, and therefore the LED stops blipping completely. Both tasks
are now blocked indefinitely and the MCU is placed into its 'Stop' low power
state.

Pressing the button one final time results in the semaphore being 'given'
to unblock the Tx task, the CPU clocks being returned to their pre-stop
state, and the block time being reset to its 'short' time. The system is
then back to its initial condition with the LED blipping rapidly.

Functionality with configCREATE_LOW_POWER_DEMO set to 0

If configCREATE_LOW_POWER_DEMO is set to 0 then main() calls main_full().
main_full() is implemented in the main_full.c C source file.

main_full() creates a comprehensive test and demo application
that demonstrates:

The created tasks are from the set of standard demo
tasks. Standard demo tasks are used by all RTOS port demo applications.
They have no specific functionality, and are created just to demonstrate how to use the FreeRTOS API,
and test the RTOS port.

A 'check' software timer is created that periodically inspects the standard
demo tasks to ensure all the tasks are functioning
as expected. The check software timer's
callback function toggles the LED on the STM32L Discovery Board.
This gives a visual feedback of the
system health. If the LED is toggling every 3 seconds, then the
check software timer has not discovered any problems. If the LED is
toggling every 200 milliseconds, then the check software timer has
discovered a potential problem in at least one task.

Building and executing the demo application

Open FreeRTOS/Demo/CORTEX_STM32L152_Discovery_IAR/RTOSDemo.eww
from within the IAR IDE.

Open FreeRTOSConfig.h, and set configCREATE_LOW_POWER_DEMO to generate either
the tickless low power demo, or the full test and demo application, as
required.

Ensure the target hardware is connected to the host computer using a suitable
USB cable.

Press F7 to build the project. The demo should build without any errors
or warnings.

After the build completes, press CTRL+D to program the STM32L microcontroller
flash memory, start a debug session, and have the debugger break on entry
into the main() function.

configLIBRARY_LOWEST_INTERRUPT_PRIORITY and configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY

Whereas configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY
are full eight bit shifted values, defined to be used as raw numbers directly
in the ARM Cortex-M3 NVIC registers, configLIBRARY_LOWEST_INTERRUPT_PRIORITY
and configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY
are equivalents that are defined using just the 4 priority bits implemented in the STM32L
NVIC.
These values are provided because the CMSIS library function NVIC_SetPriority() and
STM32 standard peripheral library functions requires the un-shifted 4 bit format.

Attention please!: See the page dedicated to setting interrupt priorities on ARM Cortex-M devices. Remember that ARM Cortex-M cores use
numerically low priority numbers to represent HIGH priority interrupts. This
can seem counter-intuitive and is easy to forget! If you wish to assign an
interrupt a low priority do NOT assign it a priority of 0 (or other low numeric
value) as this will result in the interrupt actually having the highest priority
in the system - and therefore potentially make your system crash if this
priority is above configMAX_SYSCALL_INTERRUPT_PRIORITY. Also, do not leave
interrupt priorities unassigned, as by default they will have a priority of 0
and therefore the highest priority possible.

The lowest priority on a ARM Cortex-M core is in fact 255 - however different
ARM Cortex-M microcontroller manufacturers implement a different number of priority bits and supply library
functions that expect priorities to be specified in different ways. For example,
on ST STM32 ARM Cortex-M3 microcontrollers, the lowest priority you can specify is in fact 15 - this is defined by the constant
configLIBRARY_LOWEST_INTERRUPT_PRIORITY in FreeRTOSConfig.h. The highest priority
that can be assigned is always zero.

NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 ) must the called before
any other interrupt priority related functions from the STM32 Standard peripheral
library, as it is in the demo provided.

Each port #defines 'BaseType_t' to equal the most efficient data type for that
processor. This port defines BaseType_t to be of type long.

Interrupt service routines

Unlike many FreeRTOS ports, interrupt service routines that cause a context switch have
no special requirements, and can be written as per the compiler documentation.
The macro portEND_SWITCHING_ISR() can be used to request a context switch from
within an interrupt service routine.

Note that portEND_SWITCHING_ISR() will leave interrupts enabled.

The following source code snippet is provided as an example. The interrupt
uses a semaphore to synchronise with a task (not shown), and calls portEND_SWITCHING_ISR()
to ensure the interrupt returns directly to the task if the task has an equal
or higher priority than the interrupted task. See the function
EXTI0_IRQHandler() in the file main_low_power.c included in this demo project for another
example.

void Dummy_IRQHandler(void)
{
long lHigherPriorityTaskWoken = pdFALSE;
/* Clear the interrupt if necessary. */
Dummy_ClearITPendingBit();
/* This interrupt does nothing more than demonstrate how to synchronise a
task with an interrupt. A semaphore is used for this purpose. Note
lHigherPriorityTaskWoken is initialised to zero. */
xSemaphoreGiveFromISR( xTestSemaphore, &lHigherPriorityTaskWoken );
/* If there was a task that was blocked on the semaphore, and giving the
semaphore caused the task to unblock, and the unblocked task has a priority
higher than the current Running state task (the task that this interrupt
interrupted), then lHigherPriorityTaskWoken will have been set to pdTRUE
internally within xSemaphoreGiveFromISR(). Passing pdTRUE into the
portEND_SWITCHING_ISR() macro will result in a context switch being pended to
ensure this interrupt returns directly to the unblocked, higher priority,
task. Passing pdFALSE into portEND_SWITCHING_ISR() has no effect. */
portEND_SWITCHING_ISR( lHigherPriorityTaskWoken );
}

Only FreeRTOS API functions that end in "FromISR" can be called from an
interrupt service routine - and then only if the priority of the interrupt
is less than or equal to that set by the configMAX_SYSCALL_INTERRUPT_PRIORITY
configuration constant (or configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY).

Resources used by FreeRTOS

When configCREATE_LOW_POWER_DEMO is set to 0 the standard FreeRTOS Cortex-M port is
used, which requires exclusive use of the SysTick and PendSV interrupts. SVC number #0 is also used.

When configCREATE_LOW_POWER_DEMO is set to 1 exclusive access to the TIM2
peripheral is required.

Memory allocation

Source/Portable/MemMang/heap_4.c is included in the ARM Cortex-M3 demo application project to provide the memory
allocation required by the RTOS kernel.
Please refer to the Memory Management section of the API documentation for
full information.