Download FreeRTOS

Quality RTOS & Embedded Software

New FreeRTOS Long Term Support version released
Simplifying Authenticated Cloud Connectivity for Any Device.
Designing an energy efficient and cloud-connected IoT solution with CoAP.
Introducing FreeRTOS Kernel version 11.0.0:
FreeRTOS Roadmap and Code Contribution process.

Infineon TriCore Demo
Using the Free TriCore Entry Toolchain
[RTOS Ports]

Infineon TriBoard TC1782 starter kit

This page documents the FreeRTOS demo application for the Infineon TriCore processor. The demo application uses the Free TriCore Entry Tool Chain, which consists of the HighTec GCC build tools, and a debugger, both of which are integrated into an Eclipse based environment.

The demo project is pre-configured to run on the Infineon TriBoard TC1782 starter kit, which is fitted with a TC1782 processor.

The FreeRTOS TriCore port supports a full interrupt nesting model, and does not completely disable interrupts, other than where architectural constrains necessitate it for correct assembly instruction sequencing purposes.

This demo application demonstrates:

Thanks to William Davy for his assistance in the creation of this port.

IMPORTANT! Notes on using the Infineon TriCore port and demo application

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, and every demo application. That means it contains many more files than are required to use the TriCore port, or the official TriCore demo application. See the Source Code Organization section of this web site for a description of the downloaded files, and information on creating a new project.

The TriCore demo Eclipse project is located in the FreeRTOS/Demo/TriCore_TC1782_TriBoard_GCC directory, but the directory requires a preparation step before the project can be imported into an Eclipse workspace.

Preparing the Eclipse project directory

Eclipse projects can be either standard makefile projects, or managed make projects. The official FreeRTOS TriCore demo project is a managed make project. This means that either:
  1. All the source files required 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 in this case, so all the required source files must be copied from their default locations in the FreeRTOS directory structure, into FreeRTOS/Demo/TriCore_TC1782_TriBoard_GCC. The batch file FreeRTOS/Demo/TriCore_TC1782_TriBoard_GCC/RTOSDemo/
is provided for this purpose.

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

The files that the batch file copies are:

  1. The core FreeRTOS kernel source files.

  2. A set of standard demo task implementations.

TriCore TC1782 Demo Application


The demo application can be configured to provide very simply 'blinky' style functionality, or a full and comprehensive test and demonstration of the FreeRTOS functionality. The #define mainCREATE_SIMPLE_LED_FLASHER_DEMO_ONLY, which is located in main.c, is used to switch between the two.

Demo application tasks are split between standard demo tasks, and demo specific tasks. Standard demo tasks are used by all FreeRTOS ports and demo applications. They have no purpose other than to demonstrate the FreeRTOS API, and test a port.

Set to 1 This creates a very simple example that creates three standard demo "flash" tasks. Each of the three tasks toggles an LED at a fixed but different frequency. LEDs P5.0, P5.1 and P5.2 are used.
Set to 0 This is a very comprehensive demo that creates 42 tasks before starting the RTOS scheduler, then continuously dynamically creates and deletes another two tasks as the application executes.

It creates many queues, software timers and different types of semaphore. The tasks consist mainly of the standard demo tasks.

The demo also includes application specific "register test" tasks. These are idle priority tasks that start by filling all the generic processor registers with known values, then repeatedly check that each register maintains its expected value, as it gets swapped in and out, for the lifetime of the task. Each of the two register check tasks uses a different set of known values, and a value being unexpectedly changed is symptomatic of an error in the context switching mechanism.

Finally, the demo creates an application specific task to check interrupt nesting functionality. The task uses a high priority, high frequency interrupt, to synchronise with a task using a semaphore. Testing has shown that the test generates a nesting depth that is at least three deep, as it nests with the UART interrupt, that itself nests with the RTOS tick interrupt. In theory, as the UART itself uses two interrupts, an extra level of nesting could also occur.

A 'check' task is created that periodically inspects the standard demo tasks, register test tasks, and the interrupt nesting test tasks, to ensure they are all operating as expected. The check task toggles LED P5.7 to give visual feedback of the system status. If LED P5.7 toggles every 5 seconds, then the check task has not discovered any potential problems with the execution of the test/demo application. If the rate at which LED P5.7 toggles increases to every 500 milliseconds, then the check task has discovered a potential problem with the behaviour of at least one task.

Like the simple flasher demo, the comprehensive demo creates the standard demo flash tasks, which toggle LEDs P5.0, P5.1 and P5.2 at fixed but different frequencies.

Hardware setup

The demo application includes tasks that send and receive characters through a UART. The characters sent by one task must be received by another. An error condition is flagged if any character is missing, or received out of order. For this reason, the UART is configured to use its internal loopback mode to ensure that every transmitted character is also received. Two things should be noted about the UART configuration:
  1. The UART has only ever been used in loopback mode. The baud rate calculation has never been verified by connecting the UART to external equipment.

  2. FreeRTOS queues are used to pass characters into, and out of, the UART interrupt handlers. This is a very inefficient implementation if the UART is being used to handle streaming data. It is used in this case to deliberately load the system, and test the operation of the FreeRTOS safe API queue functions in an environment that supports interrupt nesting.

The LEDs used by the demo application are hard wired onto the TriBoard main board, so no explicit hardware setup is required.

Importing, building, and debugging the FreeRTOS demo application

  1. Ensure the required tools have been downloaded and installed.

  2. Ensure the FreeRTOS/Demo/TriCore_TC1782_TriBoard_GCC/RTOSDemo/
    batch file has been executed.

  3. Start the installed Eclipse for TriCore tool, and create a new Workspace or select an existing workspace as appropriate. If necessary, proceed to the Eclipse workbench.

  4. Select "Import..." from the File menu.

  5. Select "Existing projects into Workspace" from the "General" category, then click Next.

    Selecting "Existing projects into Workspace"

  6. In the next dialogue, select FreeRTOS/Demo/TriCore_TC1782_TriBoard_GCC as the root directory, then select "FreeRTOS_Demo" as the project.

    Selecting the root directory and project

  7. Click "Finish" to complete the import process.

  8. Right click on the project name in the Eclipse Project Explorer window, then use the "Build Configurations->Set Active" option from the pop up menu to select between a build configuration that executes entirely from RAM, and a build configuration that executes from the TriCore Flash memory. NOTE: The RAM build configuration is configured to use size optimisation.

  9. To actually build the project, simply select "Build Project" from the Eclipse Workbench Project menu.

  10. Finally, to start a debug session, ensure the TriBoard is powered and correctly connected via USB a cable to the host computer, then click the "debug" speed button in the Eclipse IDE.

    The debug speed button in the TriCore Eclipse IDE

When executing, the full demo application will behave as follows:

  • LEDs P5.0, P5.1 and P5.2 are under the control of the standard 'flash' tasks. Each will toggle at a fixed but different frequency, with P5.0 using the highest frequency, and P5.2 using the lowest.

  • LED P5.7 is under the control of the 'check' task. It will toggle every five seconds if all the other tasks are reporting their status as healthy. It will toggle every 500ms if any task has ever reported an error.

  • LEDs P5.5 and P5.6 are toggled as characters are transmitted and received by the standard demo ComTest tasks. The toggle rate will be too fast to perceive, and the LEDs will appear to be on.

RTOS Configuration and Usage Details

FreeRTOS TriCore RTOS port specific configuration

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

    Sets the frequency of the RTOS tick. The supplied value of 1000Hz is useful for testing the RTOS kernel functionality, but is faster than needed by most applications. Lowering this frequency will improve efficiency.


    Defines the maximum interrupt priority from which FreeRTOS API functions can be called. Interrupts at or below this priority can call FreeRTOS API functions provided that the API function ends in 'FromISR'. Interrupts above this priority cannot call any FreeRTOS API functions, but will not be disabled by the RTOS kernel (over an above the limitations imposed by the architecture mentioned at the top of this file). Interrupts that have a priority above configMAX_SYSCALL_INTERRUPT_PRIORITY are therefore suitable for functionality that requires very high timing accuracy.

The TriCore port layer #defines 'BaseType_t' to 'long'.

TriCore resources used by FreeRTOS

FreeRTOS uses, and requires exclusive use of:
  • Interrupt priority 1.
  • Interrupt priority 2.
  • Syscall trap number 0.
  • The frequency at which the system timer (STM) executes.
  • The system timer (STM) compare match 0 configuration and interrupt.

Trap handlers

Default trap handlers are defined for unused traps in Demo/TriCore_TC1782_TriBoard_GCC/RTOSDemo/FreeRTOS_Source/portable/GCC/
. The trap handlers are declared as weak functions. This allows an application writer to redefine them within their application code, if desired.

The SysCall trap is used by the RTOS kernel, and defined in port.c.

Writing interrupt service routines (ISRs)

Interrupt service routines (ISRs) are written and installed using the standard facilities provided by the compiler libraries. Examples can be found in serial.c and InterruptNestTest.c.

The priorities of the interrupts used by the demo are defined in FreeRTOSConfig.h. Note that interrupt priorities 1 and 2 are used by the RTOS kernel, and must not be used or modified.

Often, an ISR wants to cause a context switch, so the task that the ISR returns to when the ISR processing is completed is different from the task that the ISR originally interrupted. This would be the case if the ISR caused a task to unblock, and the task that was unblocked has a priority above the task in the Running state (the task that was interrupted). The macro portYIELD_FROM_ISR() is provided for this purpose. portYIELD_FROM_ISR() takes a single parameter: If the parameter is zero, a context switch is not performed, if the parameter is non-zero, a context switch is performed. A very simple example of this is found in InterruptNestTest.c, and is replicated below:

static void prvPortHighFrequencyTimerHandler( int iArg )
static volatile unsigned long ulExecutionCounter = 0UL;

/* Variable used to determine if a context switch is required.  This must be
initialised to pdFALSE (0). */
unsigned long ulHigherPriorityTaskWoken = pdFALSE;

    /* Clear the interrupt source. */
    STM_ISRR.reg = 1UL << 2UL;

    /* Reload the Compare Match register for X ticks into the future.*/
    STM_CMP1.reg += ulCompareMatchValue;

    /* Note how many times this ISR has executed. */

    /* Do the number of executions equal the number expected in a 10ms period? */
    if( ulExecutionCounter >= ulInterruptsPer10ms )
        /* Give the semaphore to unblock the task that is synchronising with
        this interrupt.  Giving this semaphore will unblock the task, and if the
        priority of the unblocked task is above that of the task that is currently
        in the Running state (the task that this interrupt interrupted), then
        ulHigherPriorityTaskWoken will be set to true within this function call
        to indicate that a context switch is required. */
        xSemaphoreGiveFromISR( xHighFrequencyTimerSemaphore, 
                               &ulHigherPriorityTaskWoken );

        /* Start counting again. */
        ulExecutionCounter = 0UL;

    /* Context switch on exit if necessary.  See the comment above the call to
    xSemaphoreGiveFromISR() just above. */
    portYIELD_FROM_ISR( ulHigherPriorityTaskWoken );

Memory allocation

Source/Portable/MemMang/heap_2.c is included in the TriCore 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.

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