Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training

FreeRTOS on the Atmel SAM4E-EK
Including FreeRTOS+CLI, FreeRTOS+FAT SL and FreeRTOS+UDP
[RTOS Ports]


This page presents the FreeRTOS port and demo application for the ATSAM4E - a 32bit microcontroller from Atmel that has an ARM Cortex-M4F core. The demo builds with the feature rich and free Atmel Studio IDE, and targets the SAM4E-EK evaluation hardware.

The demo project can be configuration to build either a simple blinky demo or a comprehensive test and demo application. The comprehensive application uses the FreeRTOS+CLI command line interface, the FreeRTOS+UDP UDP/IP stack and the FreeRTOS+FAT SL super lean DOS compatible FAT file system.

RTOS running on Atmel ARM Cortex-M microcontroller
SAM4E-EK with FreeRTOS jpg
Click to enlarge
ARM Cortex-M4 RTOS viewer in Atmel Studio
Atmel Studio with FreeRTOS kernel
aware plug-in. Click to enlarge

IMPORTANT! Notes on using this ARM Cortex-M4F demo

Please read all the following points before using this RTOS port.

  1. Source Code Organization
  2. The Demo Application
  3. Configuration and Usage Details
See also the FAQ My application does not run, what could be wrong?

Source Code Organization

The FreeRTOS download contains the source code and demo application projects for all the RTOS ports, so most of the files it contains are not relevant to the SAM4E-EK demo. See the Source Code Organization section for a description of the downloaded files.

The Atmel Studio project that builds the SAM4E-EK RTOS demo is located in the FreeRTOS/Demo/CORTEX_M4_ATSAM4E_Atmel_Studio directory. Note: The Atmel Studio project references files from multiple directories within the FreeRTOS and FreeRTOS+ directory trees, so will only build from this directory.

The Demo Application


The constant mainCREATE_SIMPLE_BLINKY_DEMO_ONLY, which is defined at the top of main.c, is used to switch between a simple 'blinky' style starter project and the more comprehensive application that includes the additional FreeRTOS+ command line, networking and FAT file system components.


When mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is set to 1 main() calls main_blinky(). main_blinky() creates a very simple example that uses one software timer, one queue and two tasks.
  • The Blinky Software Timer:

    This demonstrates an auto-reload software timer. The timer callback function does nothing but toggle an LED.

  • The Queue Send Task:

    The queue send task is implemented by the prvQueueSendTask() function. The task sits in a loop that sends the value 100 to the queue every 200 milliseconds.

  • The Queue Receive Task:

    The queue receive task is implemented by the prvQueueReceiveTask() function. The task sits in a loop blocking on attempts to read from the queue (no CPU cycles are consumed while it is blocked), toggling an LED each time a value is received. The queue send task writes to the queue very 200 milliseconds, so the queue receive task toggles the LED every 200 milliseconds.


When mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is set to 0 main() calls main_full(). main_full() creates an interactive test and demo application that creates numerous RTOS tasks and software timers, and includes network connectivity.

If ipconfigUSE_DHCP is set to 1 in FreeRTOSIPConfig.h then the SAM4E-EK must be connected to a network that includes a DHCP server. If ipconfigUSE_DHCP is set to 0 in FreeRTOSIPConfig.h then the demo will use the static IP address configured by the constants configIP_ADDR0 to configIP_ADDR3 which are defined in FreeRTOSConfig.h (rather than FreeRTOSIPConfig.h). In each case the IP address used will be displayed on the LCD after it has been obtained.

Static IP addresses must be compatible with the network to which they are being connected. This will be ensured if the first three octets of the configured IP address match the first three octets of other IP addresses already on the network.

The MAC address is configured using the constants configMAC_ADDR0 to configMAC_ADDR5, which are also defined in FreeRTOSConfig.h. Each node connected to the network must use a unique MAC address.

Functionality included in the demo:

  • FreeRTOS+CLI accessed via FreeRTOS+UDP Sockets

    FreeRTOS+UDP is used to provide the input and output for the command line interface. The command line interface can be accessed through any UDP dumb terminal. By default port 5001 is used to send to the CLI, and port 5002 is used to receive replies from the CLI. The image below shows the required configuration when the free YAT terminal is used for this purpose.

    As always with FreeRTOS+CLI, enter "help" to see a list of registered commands, which in this case includes a set of generic commands, a set of FAT file system related commands, and a set of networking related commands.

    Note that, at the time of writing at least, the network driver included in the demo is of a basic nature, and will not demonstrate the full potential of the Ethernet hardware.

    Connecting to the RTOS via UDP networking
    Configuring YAT to connect to
    a CLI on IP address
    Click to enlarge.
    RTOS command line session
    A sample CLI session.
    Click to enlarge

  • Creating, viewing, copying and deleting files with FreeRTOS+FAT SL

    The FAT file system creates a set of example files that can be accessed and manipulated through the command line interface. The functionality of the example is the same as that described on the FreeRTOS+FAT SL Win32 simulator demo documentation page - where there is also a video demonstration. Note: Use the instructions on this page to connect to the CLI, not the instructions on the Win32 demo page, or the instructions in the video.

  • FreeRTOS+UDP Echo Client Example

    If mainINCLUDE_ECHO_CLIENT_TASKS is set to 1 at the top of main_full.c then the standard UDP echo example will be created. The IP address of the echo server is set by the constants configECHO_SERVER_ADDR0 to configECHO_SERVER_ADDR3 within FreeRTOSConfig.h.

  • Standard Demo Tasks and the Check Software Timer

    The demo creates lots of the standard demo tasks. These have no particular functionality but serve to test the RTOS port and demonstrate the FreeRTOS API.

    The LED marked D2 is controlled by a standard demo flash software timer.

    A 'check software timer' is created to provide visual feedback of the status of the standard demo tasks. The software timer monitors all the other tasks, and then toggle LED D4. If all the other tasks are executing as expected the LED will toggle every 3 seconds. If a suspected error has been found in any of the other tasks the toggle rate will increase to 200ms.

Building and debugging the demo application with Atmel Studio

  1. Open the project from within the Atmel Studio IDE (the name and location of the project is detailed in the Source Code Organization section near the top of this page).

  2. Connect to the SAM4E-EK hardware using a suitable debugger interface. The project was created and tested using a J-Link.

  3. Select "Rebuild RTOSDemo" from the Atmel Studio "Build" menu (or press F7) to build the demo project.

  4. Select "Start Debugging and Break" from the Atmel Studio "Debug" menu to program the microcontroller flash memory and start a debug session.

Configuration and Usage Details

ARM Cortex-M4 FreeRTOS port specific configuration

Configuration items specific to this demo are contained in FreeRTOS/Demo/CORTEX_M4_ATSAM4E_Atmel_Studio/src/config/FreeRTOSConfig.h. The constants defined in this file can be edited to suit your application. In particular -
  • configTICK_RATE_HZ

    This sets the frequency of the RTOS tick interrupt. The setting used by this demo depends on the configCREATE_LOW_POWER_DEMO setting.


    See the RTOS kernel configuration documentation for full information on these configuration constants.


    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 4 priority bits implemented in the SAM4 NVIC. These values are provided because the CMSIS library function NVIC_SetPriority() 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 Atmel SAM4 ARM Cortex-M4 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.

It is also recommended to ensure that all priority bits are assigned as being preemption priority bits, and none as sub priority bits, as they are in the provided demo.

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.

void Dummy_IRQHandler(void)
long lHigherPriorityTaskWoken = pdFALSE;

    /* Clear the interrupt if necessary. */

    /* 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

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.

Memory allocation

Source/Portable/MemMang/heap_4.c is included in the ARM Cortex-M4 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.


Note that vPortEndScheduler() has not been implemented.

[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS