You can migrate your project to FreeRTOS 202210.01 LTS or subscribe to the FreeRTOS Extended Maintenance Plan. See the blog post.
FreeRTOS website now available in Simplified Chinese
Search and browse content in your preferred language. See the blog post.
New FreeRTOS Long Term Support version now available.
Receive security patches and critical bug fixes on FreeRTOS libraries for two years. See the blog post.
FreeRTOS Extended Maintenance Program (EMP) registration now open.
Providing security patches and critical bug fixes on FreeRTOS Long Term Support (LTS) versions for up to 10 additional years. See the blog post.
Microchip ARM Cortex-M4F CEC1302
Low Power RTOS Demo - Using the Keil, GCC and MikroC development tools
[RTOS Ports]
Introduction
This page documents an RTOS demo application for the ARM Cortex-M4F based
CEC1302 microcontroller
from Microchip. Pre-configured projects are provided for the following
compiler and tool combinations:
The project can be configured to create either a simple blinky style project
that demonstrates how power can be saved by using the
RTOS's tickless idle feature,
or a more comprehensive test and demo application that tests the port's integrity
and demonstrates many RTOS features.
IMPORTANT! Notes on using the FreeRTOS CEC1302 demo project
Please read all the following points before using this RTOS port.
The FreeRTOS zip file contains the source files for all the FreeRTOS
ports, and all the demo applications. Only a few of these files 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 Keil uVision project that uses the ARM compiler is called
RTOSDemo.uvprojx, and is located in the
FreeRTOS/Demo/CORTEX_M4F_CEC1302_Keil_GCC/Keil_Specific
directory of the main FreeRTOS download.
The Keil uVision project that uses the GCC compiler is also called
RTOSDemo.uvprojx, and is located in the
FreeRTOS/Demo/CORTEX_M4F_CEC1302_Keil_GCC/GCC_Specific
directory of the main FreeRTOS download.
The MikroC Pro for ARM project is called
RTOSDemo.mcpar, and is located in the
FreeRTOS/Demo/CORTEX_M4F_CEC1302_MikroC/MikroC_Specific
directory of the main FreeRTOS download.
Caution: The MikroC compiler will leave many temporary files
throughout your project directory structure, the built in editor
is not compatible with the formatting conventions used by the RTOS source files,
and to allow the FreeRTOS source files to be built the FreeRTOS MikroC port layer
#defines the 'const' keyword away to nothing.
The Microchip ARM Cortex-M4 RTOS Demo Application
Hardware set up - uVision projects
Normally RTOS demo applications indicate their status by controlling the rate at
which an LED is toggled. However, the uVision demos do not target any specific
hardware, so are not configured to toggle any specific LED on any particular IO
port. Instead, a variable called ulLED is incremented each time an LED would
otherwise be toggled.
The ulLED variable is incremented by the macro configTOGGLE_LED(), which is
defined in FreeRTOSConfig.h. If your target hardware has a spare LED, then
configTOGGLE_LED() can be updated to make use of the LED. Otherwise ulValue can
be added to the uVision IDE's data watch window, where its value will be seen to
updated as the RTOS demo application executes (provided a capable debug interface
is used, such as a ULINK).
The ARM compiler and GCC compiler versions of the uVision projects can also
be executed on the Clicker hardware described in the next section by creating an
adapter cable that maps the Mikro mProg cable to a standard ARM JTAG connector.
The required pin-out is detailed in the table below (assumes a 20-pin JTAG connector).
Signal Names
ARM 20 Pin #
mPROG Pin #
VCC +3.3V
1
1
Ground
20
9
JTAG_TDI
5
8
JTAG_TMS
7
2
JTAG_TCLK
9
4
JTAG_TDO
13
6
RTCK
11 and 12
Ground
Hardware set up - MikroC Pro for ARM project
The MikroC project is pre-configured to run on a
CEC1302 Clicker board, and uses
the LED built onto that hardware.
Functionality
The project provides two RTOS demo applications. A simple blinky style project
that demonstrates low power tickless functionality, and a more comprehensive
test and demo application. The configCREATE_LOW_POWER_DEMO setting, which is
defined in FreeRTOSConfig.h, is used to select between the two.
Functionality with configCREATE_LOW_POWER_DEMO set to 1
When configCREATE_LOW_POWER_DEMO is set to 1 main() calls main_low_power(), which
creates a very simple demo as follows:
Two tasks are created, an Rx task and a Tx task.
The Rx task blocks on a queue to wait for data, blipping (turning on then
off again) an LED (or toggling
the ulLED variable) each time data is received. The LED is only blipped
on briefly so it does not effect current consumption too much.
The Tx task sends a value through the queue to the Rx
task every 1000ms (resulting in the Rx task exiting the blocked state to blip
the LED).
Observed behaviour when configCREATE_LOW_POWER_DEMO is set to 1
Both tasks spend most of their time in the Blocked state, during which periods
the RTOS tick is turned off, and the ARM Cortex-M4F is placed into a low power state.
Every 1000ms the MCU will come out of the low power state, turn the LED on,
return to the low power state for 10ms, before leaving the low power
state again to turn the LED off. This will be observed as a short blip on the LED
every 1000ms.
The demo is provided with a low power tickless implementation
that uses the CEC1302 hibernation timer to generate the RTOS tick interrupt.
This CEC1302 specific
tickless implementation includes the same configPRE_SLEEP_PROCESSING() and
configPOST_SLEEP_PROCESSING() macros that are described on
the page that documents
the generic Cortex-M tickless implementation. The pre sleep macro can be
defined to take additional application specific actions to improve energy efficiency
before entering the low power state, and the post sleep macro can be defined to
reverse any of the actions taken by the pre sleep macro. For example, if the
pre-sleep macro is defined to turn a peripheral off, and the post sleep macro is
defined to turn the peripheral on again, then the peripheral will automatically
be turned off prior to each entry into the sleep mode, and automatically turned back
on again on each exit from the sleep mode.
Functionality with configCREATE_LOW_POWER_DEMO set to 0
When configCREATE_LOW_POWER_DEMO is set to 0 main()
calls main_full(), which 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 FreeRTOS 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' task is created that periodically inspects the standard
demo tasks to ensure all the tasks are functioning
as expected. The check task toggles an LED (or increments the ulLED variable).
This gives a visual feedback of the
system health. If an LED is toggling every 3 seconds, then the
check task has not discovered any problems. If the LED is
toggling every 200 milliseconds, then the check task has
discovered a problem in one or more tasks.
Building and executing the demo application
Using the uVision project with the GCC compiler
Ensure a suitable GCC compiler is installed on the host computer. The
project was created and tested with the arm-none-eabi-gcc compiler,
pre-built binaries for which are freely available from the
launchpad.net
website.
Open FreeRTOS/Demo/CORTEX_M4F_CEC1302_Keil_GCC/GCC_Specific/RTOSDemo.uvprojx
from within the Keil IDE.
Open the Manage Project Items window within the uVision IDE ("Project->Manage->Project Items" menu item)
and set the GCC prefix and installation folder to be correct for your
host computer.
Setting the path to the GCC compiler binary
Note the path does not include the training "/bin"
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 through a
suitable debug connector, such as a ULINK2.
Select 'Rebuilt All Target Files' from the IDE's 'Project' menu, the
RTOSDemo project should compile without any errors or warnings.
After the build completes, select "Start/STOP Debug Session" from the IDE's Debug
menu to download the application to the CEC1302 ARM Cortex-M4F microcontroller RAM memory,
start a debug session, and have the debugger break on entry into the main() function.
If the debug session does not start as expected then ensure the debug options,
and in particular the "Connect & Reset Options" section of the debug options,
are set as shown below.
The required connect and reset options
Using the uVision project with the ARM compiler
Open FreeRTOS/Demo/CORTEX_M4F_CEC1302_Keil_GCC/Keil_Specific/RTOSDemo.uvprojx
from within the Keil 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 through a
suitable debug connector, such as a ULINK2.
Select 'Rebuilt All Target Files' from the IDE's 'Project' menu, the
RTOSDemo project should compile without any errors or warnings, although
a warning may be generated by the linker as, to enable the maximum number
of tests to be added to the comprehensive demo, the linker script is
configured to place both code and data in the same named section.
After the build completes, select "Start/STOP Debug Session" from the IDE's Debug
menu to download the application to the CEC1302 ARM Cortex-M4F microcontroller RAM memory,
start a debug session, and have the debugger break on entry into the main() function.
If the debug session does not start as expected then ensure the debug options,
and in particular the "Connect & Reset Options" section of the debug options,
are set as shown by the image provided as part of the GCC instructions
above.
Using the MikroC Pro compiler for ARM and the Clicker hardware
Caution: The MikroC compiler will leave many temporary files
throughout your project directory structure, the built in editor
is not compatible with the formatting conventions used by the RTOS source files,
and to allow the FreeRTOS source files to be built the FreeRTOS MikroC port layer
#defines the 'const' keyword away to nothing.
Open FreeRTOS/Demo/CORTEX_M4F_CEC1302_MikroC/MikroC_Specific/RTOSDemo.mcpar
from within the MikroC Pro IDE.
Open the Search Paths window ("Projects->Edit Search Paths" menu item)
and update the paths to the source files and header files to be correct
for your host computer.
Setting the path to source and header files
As provided, the MikroC demo uses the FreeRTOS/Source/portable/MemMang/heap_4.c
memory allocator, and a malloc failed hook is
defined. It is necessary to make a small edit to the heap_4.c source file
to make it compatible with the MikroC compiler. Open heap_4.c and locate
the following code:
Move the line highlighted (the line starting 'extern') from its current
position to the top of the source file so it has file scope rather than
block scope.
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.
Select 'Build' from the IDE's 'Build' menu to create an executable image.
Ensure the Clicker hardware is powered through its USB port, and connected
using a MikroProg flash programmer, before selecting "mE Programmer"
from the "Tools" menu to download the executable image to the CEC1302 ARM Cortex-M4F
microcontroller. If the download does not start as expected then ensure
the Programmer/Debugger Options are as shown in the image below
("Tools->Programmer/Debugger Options" menu item).
The required programmer and debug options
After the download completes, select "Start Debugger" from the "Debug"
menu to start a debug session, and run the application.
If the debugger does not start as expected then ensure
the Programmer/Debugger Options are as shown in the image above
("Tools->Programmer/Debugger Options" menu item).
This sets the frequency of the RTOS tick interrupt. The setting used by
this demo depends on the configCREATE_LOW_POWER_DEMO setting.
configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY
See the RTOS kernel configuration documentation for full information on these configuration constants.
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-M4 NVIC registers, configLIBRARY_LOWEST_INTERRUPT_PRIORITY
and configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY
are equivalents that are defined using just the 3 priority bits implemented in the CEC1302
NVIC.
These values are provided because the CMSIS library function NVIC_SetPriority()
requires the un-shifted 3 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 Microchip CEC1302 ARM Cortex-M4 microcontrollers, the lowest priority you can specify is in fact 7 - this is defined by the constant
configLIBRARY_LOWEST_INTERRUPT_PRIORITY in FreeRTOSConfig.h. The highest priority
that can be assigned is always zero.
It is also recommended to ensure that all priority bits are assigned as
being preemption priority bits, and none as sub priority bits.
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.
Aggregated and disaggregated interrupts
The CEC1302 can route groups of interrupt sources to the same interrupt
vector (aggregated interrupts), or route all interrupt sources to their own unique interrupt
vector (disaggregated interrupts). The RTOS itself only uses ARM Cortex-M system interrupts,
which are always routed to the standard ARM Cortex-M system vectors, but the demo
application also makes
use of btimer (basic timer) and htimer (hibernation timer) interrupts, both of
which can be aggregated or disaggregated. In order to
demonstrate both methods, the tickless low power demo is configured to use
aggregated interrupts and the comprehensive demo is configured to use disaggregated
interrupts (note the comprehensive demo uses disaggregated interrupts as the
interrupt nesting test cannot function if all the timer interrupts are routed
through the same vector).
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 portYIELD_FROM_ISR() can be used to request a context switch from
within an interrupt service routine.
Note that portYIELD_FROM_ISR() will leave interrupts enabled.
The following source code snippet is provided as an example. The interrupt
uses a direct to task notification
to synchronise with a task (not shown), and calls portYIELD_FROM_ISR()
to ensure the interrupt returns directly to the task if the task has an equal
or higher priority than the interrupted task.
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 task notification is used for this purpose.
Note lHigherPriorityTaskWoken is initialised to zero. */
vTaskNotifyGiveFromISR( xHandlingTask, &xHigherPriorityTaskWoken );
/* If the notified task was blocked waiting for the notification, and the
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 vTaskNotifyGiveFromISR(). Passing
pdTRUE into the portYIELD_FROM_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 portYIELD_FROM_ISR()
has no effect. */
portYIELD_FROM_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
FreeRTOS requires exclusive use of the SysTick and PendSV interrupts. SVC number #0 is also used.
Switching between the pre-emptive and co-operative RTOS kernels
Set the definition configUSE_PREEMPTION within FreeRTOSConfig.h to 1 to use pre-emption or 0
to use co-operative. The full demo application may not execute correctly when the co-operative RTOS scheduler is
selected.
Compiler options
As with all the ports, it is essential that the correct compiler options are used. The best way to ensure this is to base your
application on the provided demo application files.