Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Infineon XMC4500 ARM Cortex-M4F Demo
Using GCC and the Atollic development tools
[RTOS Ports]


Infineon XMC4500 Hexagon Development Kit CPU board



Introduction

The demo provided on this page is now obsolete and replaced by a new demo and documentation page

This page documents a demo application that uses the FreeRTOS GCC ARM Cortex-M4F port. It targets the Infineon XMC4000 Hexagon Development Kit CPU board, which is populated with an XMC4500 microcontroller.

To use the port, the hardware floating point unit (the FPU, or VFP) must be switched on, and the GCC compile time options must be set to generate hardware floating point instructions. The FreeRTOS port layer will itself turn the FPU on immediately before the RTOS scheduler is started, and the pre-configured demo application described on this page has all the required compiler options.

The project can be configured to create either a basic blinky style demo, or a more comprehensive test and demo application.


IMPORTANT! Notes on using the FreeRTOS GCC XMC4000 demo project

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

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

Source Code Organisation

The FreeRTOS download contains the source code for all the FreeRTOS ports, so includes many more files than are needed by this demo. See the Source Code Organization section for a description of the downloaded files and information on creating a new project.

The Eclipse project file for this demo application is located in the FreeRTOS/Demo/CORTEX_M4F_Infineon_XMC4500_GCC_Atollic directory. The Preparing the Eclipse Project section of this page contains important information on setting up the demo project directory, and importing the demo project into the Atollic IDE.



The Infineon XMC4500 Demo Application

The single Ecplise project provides two configurations. It can be configured as a simple blinky style project, or a more comprehensive test and demo application. The mainCREATE_SIMPLE_BLINKY_DEMO_ONLY definition, located at the top of main.c, is used to switch between the two at compile time.


Functionality with mainCREATE_SIMPLE_BLINKY_DEMO_ONLY set to 1

Setting mainCREATE_SIMPLE_BLINKY_DEMO_ONLY to 1 results in main() calling main_blinky(). main_blinky() sets up a very simple demo, as described below.
  • The main_blinky() Function:

    main_blinky() creates one queue, and two tasks. It then starts the RTOS scheduler.

  • The Queue Send Task:

    The queue send task is implemented by the prvQueueSendTask() function in main_blinky.c. prvQueueSendTask() sits in a loop that causes it to repeatedly block for 200 milliseconds, before sending the value 100 to the queue that was created within main_blinky(). Once the value is sent, the task loops back around to block for another 200 milliseconds.

  • The Queue Receive Task:

    The queue receive task is implemented by the prvQueueReceiveTask() function in main_blinky.c. prvQueueReceiveTask() sits in a loop where it repeatedly blocks on attempts to read data from the queue that was created within main_blinky(). When data is received, the task checks the value of the data, and if the value equals the expected 100, toggles the LED. The 'block time' parameter passed to the queue receive function specifies that the task should be held in the Blocked state indefinitely to wait for data to be available on the queue. The queue receive task will only leave the Blocked state when the queue send task writes to the queue. As the queue send task writes to the queue every 200 milliseconds, the queue receive task leaves the Blocked state every 200 milliseconds, and therefore toggles the LED every 200 milliseconds.


Functionality with mainCREATE_SIMPLE_BLINKY_DEMO_ONLY set to 0

Setting mainCREATE_SIMPLE_BLINKY_DEMO_ONLY to 0 results in main() calling main_full(). main_full() sets up a comprehensive test and demo, which demonstrates:
  • Floating point context switching.
  • Malloc failed and stack overflow hook functions. main.c also contains Tick and Idle hook functions, but FreeRTOSConfig.h is not configured to use them. See the comments in the implementation of the functions in main.c.
  • Software timers.
  • Semaphores.
  • Mutexes.
  • Queues.
Some of the created tasks are from the set of standard demo tasks, while others are specific to this demo. Standard demo tasks are used by all FreeRTOS ports and demo applications. They have no functional purpose, and exist just to demonstrate how to use the FreeRTOS API, and test the FreeRTOS implementation.

main() creates 43 tasks before starting the RTOS scheduler. The demo then dynamically and continuously creates and deletes a further two tasks while it is running.

Application specific "register test" tasks are created in addition to the standard demo tasks. These start by filling all the generic, and all the floating point registers, with known values. The tasks then repeatedly check that each register maintains the value written to it for the lifetime of the tasks. The register check tasks run at the idle priority, so will exit and re-enter the Running state frequently. The two register check tasks each fill the CPU registers with different values, and a register containing an unexpected value is symptomatic of an error in the context switching mechanism.

A 'check' software timer is created that periodically inspects the standard demo tasks, and register test tasks, to ensure all the tasks are functioning as expected. The check software timer's callback function toggles the single user LED on the XMC4500 Hexagon development kit CPU 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 problem in one or more tasks.


Hardware set up

The demo uses the LED that is soldered directly onto the CPU board PCB, so no hardware set up is required.


Preparing the Eclipse project directory

Eclipse projects can be either standard makefile projects, or managed make projects. The FreeRTOS Atollic ARM Cortex-M4F project uses a managed make project. This in turn means that either:
  1. All the source files needed to build the project must be located under the folder/directory that contains the project file itself, or
  2. The Eclipse workspace (note workspace, not project) needs to be configured to locate the files elsewhere on the hard disk.
Option 1 is used for this demo. Therefore, the directory FreeRTOS/Demo/CORTEX_M4F_Infineon_XMC4500_GCC_Atollic contains a batch file called CreateProjectDirectoryStructure.bat that copies all the required FreeRTOS source files, and some standard demo application files, into sub directories inside the demo project directory.

CreateProjectDirectoryStructure.bat must be executed before the Atollic project is imported into the Eclipse workspace.

CreateProjectDirectoryStructure.bat cannot be executed from within the Atollic IDE.


Importing the demo application into the Atollic Eclipse workspace

To import the necessary projects into an existing or new Eclipse Workspace:
  1. Select "Import" from the Atollic "File" menu. The dialogue box shown below will appear. Select "Existing Projects into Workspace".


    Importing the ARM Cortex-M4 project into the Eclipse workspace
    The dialogue box that appears when "Import" is first clicked


  2. In the next dialogue box, select FreeRTOS/Demo/CORTEX_M4F_Infineon_XMC4500_GCC_Atollic as the root directory. Then, make sure the RTOSDemo (rather than "FreeRTOS-Simple-Demo", as depicted below) project is checked in the "Projects" area, and that the Copy Projects Into Workspace box is not checked, before clicking the Finish button (see the image below for the correct check box states).


    Selecting the ARM Cortex-M4 RTOSDemo for importing into Eclipse
    Make sure the RTOSDemo project is checked (not FreeRTOS-Simple-Demo
    as depicted), and "Copy projects into workspace" is not checked


Building and executing the demo application

  1. Ensure the CreateProjectDirectoryStructure.bat batch file has been executed, that the project has been imported into the Atollic workspace, and that mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is set to generate the required demo functionality, as noted above.

  2. Ensure the target hardware is connected to the host computer using a suitable interface. The project was created using a J-Link Lite.

  3. Select 'Build All' from the IDE's 'Project' menu, the RTOSDemo project should build without any errors or warnings.

  4. After the project has built, click the "Debug" speed button in the IDE to program the microcontroller flash memory, and start a debug session.



RTOS Configuration and Usage Details


Cortex-M4F FreeRTOS port specific configuration

Configuration items specific to this demo are contained in FreeRTOS/Demo/CORTEX_M4F_Infineon_XMC4500_GCC_Atollic/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 supplied value of 1000Hz is useful for testing the RTOS kernel functionality but is faster than most applications need. Lowering the frequency will improve efficiency.

  • 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-M4F NVIC registers, configLIBRARY_LOWEST_INTERRUPT_PRIORITY and configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY are equivalents that are defined using just the 6 priority bits implemented in the XMC4000 NVIC. These values are provided because the CMSIS library function NVIC_SetPriority() requires the unshifted 6 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 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 Infineon XMC4000 ARM Cortex-M4 microcontrollers, the lowest priority you can specify is in fact 63 - 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 six 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.

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

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_2.c is included in the ARM Cortex-M4F 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.


Miscellaneous

Note that vPortEndScheduler() has not been implemented.





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


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

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

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

Xilinx Microblaze and Zynq partner