Infineon TriCore Demo Using the Free TriCore Entry Toolchain
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 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.
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.
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
All the source files required to build the project must be located under
the folder/directory that contains the project file itself, or
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
is provided for this purpose.
CreateProjectDirectoryStructure.bat must be executed before the FreeRTOS demo
project is imported into the Eclipse workspace.
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
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
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.
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:
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.
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
Ensure the FreeRTOS/Demo/TriCore_TC1782_TriBoard_GCC/RTOSDemo/ CreateProjectDirectoryStructure.bat
batch file has been executed.
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.
Select “Import…” from the File menu.
Select “Existing projects into Workspace” from the “General”
category, then click Next.
Selecting “Existing projects into Workspace”
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
Click “Finish” to complete the import process.
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.
To actually build the project, simply select
“Build Project” from the Eclipse Workbench Project menu.
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.
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 –
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.
Default trap handlers are defined for unused traps in
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
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
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. */
/* 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 );
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
Note that vPortEndScheduler() has not been implemented.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.