TI Hercules Safety MCUs RTOS Demo
RM48 and TMS570 (Cortex-R4F) Using Code Composer Studio 5
[RTOS Ports]
Introduction
This page documents the FreeRTOS demo applications for the
RM4
and TMS570
safety microcontrollers from Texas Instruments.
The demo application uses the FreeRTOS Cortex-R4 Code Composer Studio (CCS) port,
and targets the TMDXRM48USB
and TMS570 TMDX570LS31USB
USB stick evaluation boards. The project was created using CCS5.
The Hercules RM4x and TMS570 safety microcontroller family enables customers to easily
develop safety-critical products that need to meet the
requirements of the ISO 26262 and IEC 61508 safety standards. These ARM Cortex-R4 based
microcontrollers offer several options of performance, memory and peripherals. Dual-core
lockstep CPU architecture, hardware BIST, MPU, ECC and on-chip clock and voltage
monitoring are some of the key functional safety features available to meet the
needs of transportation, industrial, and medical applications. For safety critical
applications there is an easy
migration path from FreeRTOS to WITTENSTEIN high integrity systems' fully safety
certified SafeRTOS kernel.
IMPORTANT! Notes on using the FreeRTOS Cortex-R4 CCS demo project
Please read all the following points before using this RTOS port.
- Source Code Organisation
- The Demo Application
- RTOS Configuration and Usage Details
See also the FAQ My application does not run, what could be wrong?
Source Code Organisation
The Preparing the Project Directory Structure section
of this page contains important information on preparing the project directory.
The FreeRTOS zip file contains the source files for all the FreeRTOS
ports, and all the demo applications. Only a subset of the files are required
by the RM48 and TMS570 demo application.
See the Source Code Organization
section for a description of the downloaded files and information on creating a
new project.
The RM48 and TMS570 RTOS demo project is contained in the
FreeRTOS/Demo/CORTEX_R4_RM48_TMS570_CCS5 directory. The project
contains four build configurations as follows:
-
An RM48 project that uses emulated (software) floating point.
-
An RM48 project that uses hardware floating point.
-
A TMS570 project that uses emulated (software) floating point.
-
A TMS570 project that uses hardware floating point.
To select a build configuration, right click the project in the project
explorer, then select the "Build Configurations->Set Active" menu item.
The TI Cortex-R4F Demo Applications
The RM48 and TMS570 demo applications have identical functionality.
Hardware set up
The demo applications use the LEDs that are built onto the USB stick evaluation
boards, and the com test tasks (described below) use the UART in loopback mode.
Therefore, no hardware setup is required.
Functionality
The behaviour of the demo depends on the setting of mainCREATE_SIMPLE_BLINKY_DEMO_ONLY,
which is defined in main.c.
Functionality with mainCREATE_SIMPLE_BLINKY_DEMO_ONLY set to 1
If mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is set to 1 then main() will
call main_blinky(). main_blinky() creates a very simple demo as follows:
-
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.
It sends the value 100 to the queue every 200 milliseconds.
-
The Queue Receive Task:
The queue receive task is implemented by the prvQueueReceiveTask() function
in main_blinky.c. It repeatedly reads from the queue with a non zero block time
specified. This results in the task entering the
Blocked state
if the queue is empty. The task toggles the red LED each time the value 100 is
received from the queue, therefore, because the queue send task sends to
the queue every 200 milliseconds, the queue receive task exits
the Blocked state and toggle the red LED every 200 milliseconds.
Functionality with mainCREATE_SIMPLE_BLINKY_DEMO_ONLY set to 0
If mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is set to 0 then main() will
call main_full(). main_full() creates a comprehensive test and demo application
that demonstrates:
-
Software timers.
-
Queues.
-
Mutexes.
-
Semaphores.
-
UART interrupts used to demonstrate task to interrupt and interrupt
to task communications, and context switching from an interrupt service
routine.
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.
main() creates 43 tasks and 2 software timers before
starting the RTOS scheduler. The demo then dynamically and continuously creates and
deletes a further two tasks while it is running.
In addition to the standard demo tasks, the following tasks and tests are
defined and/or created within main_full():
"Check" timer - The check software timer period is set to three seconds.
The callback function associated with the check software timer checks that
all the standard demo tasks are not only still executing, but are executing
without reporting any errors. If the check software timer discovers that a
task has either stalled, or reported an error, then the error is logged and
the check software timer toggles the red LEDs. If an error has never been
latched, the check software timer toggles the green LEDs. Therefore, if the
system is executing correctly, the green LEDs will toggle every three
seconds, and if an error has ever been detected, the red LEDs will toggle
every three seconds.
"Reg test" tasks - These fill both the core and floating point registers
with known values, then check that each register maintains its expected
value for the lifetime of the tasks. Each task uses a different set of
values. The reg test tasks execute with a very low priority, so get
preempted very frequently. A register containing an unexpected value is
indicative of an error in the context switching mechanism, and will result in
the check timer (described above) toggling the red LEDs.
"LED" software timer - The callback function associated with the LED
software time maintains a pattern of spinning white LEDs.
Preparing the Code Composer Studio (Eclipse) project directory
Eclipse projects can be either standard makefile projects, or managed make projects.
The RM48 and TMS570 projects are managed make projects. This in turn means that
either:
- All the source files needed 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. To that end, the directory FreeRTOS/Demo/CORTEX_R4_RM48_TMS570_CCS5
contains a batch file called CreateProjectDirectoryStructure.bat that
will copy all the required FreeRTOS source files into sub directories inside the
demo project directory.
CreateProjectDirectoryStructure.bat must be executed before the CCS
project is imported into the Eclipse workspace.
CreateProjectDirectoryStructure.bat cannot be
executed from within the CCS Eclipse IDE.
Importing the demo application project into the CCS Eclipse workspace
To import the Cortex-R4F project into an existing or new Eclipse Workspace:
-
Select "Import" from the CCS "File" menu. The dialogue box shown below
will appear. Select "Existing Projects into Workspace".
The dialogue box that appears when "Import" is first clicked
-
In the next dialogue box, select FreeRTOS/Demo/CORTEX_R4_RM48_TMS570_CCS5
as the root directory. Then, make sure the CORTEX_R4_RM48_TMS570_CCS5
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,
the finish button is not visible in the image).
Make sure that two projects are checked, and "Copy projects into workspace" is not checked
Cortex-R4 FreeRTOS port specific configuration
Configuration items specific to this demo are contained in FreeRTOS/Demo/CORTEX_R4_RM48_TMS570_CCS5/FreeRTOSConfig.h.
The constants defined in this file can be edited to suit your application. In particular -
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.
The following snippet of source code, taken from serial.c in the demo application,
provides an example. NOTE: The serial driver in the demo application is
provided to test the port and demonstrate task to interrupt and interrupt to
task communication. It is not intended to provide an example of an efficient
implementation. Production implementations should not pass individual characters
on queues, and should make use of hardware features such as DMAs and FIFOs.
/* The interrupt implementation uses the standard __interrupt compiler keyword. */
__interrupt void vSCIInterruptHandler( void )
{
/* xHigherPriorityTaskWoken must be initialised to pdFALSE. */
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
char cChar;
BaseType_t xVectorValue = serialSCI_INTVEC0_REG;
switch( xVectorValue )
{
case serialRECEIVE_BUFFER_FULL:
/* Receive buffer full interrupt, send received char to a queue.
The address of xHigherPriorityTaskWoken is used as a parameter. */
cChar = serialSCI_RD_REG;
xQueueSendFromISR( xRxedChars, &cChar, &xHigherPriorityTaskWoken );
break;
}
/* If calling xQueueSendFromISR() above caused a task to leave the blocked
state, and the task that left the blocked state has a priority above the
task that this interrupt interrupted, then xHighPriorityTaskWoken will have
been set to pdTRUE. If xHigherPriorityTaskWoken equals true then calling
portYIELD_FROM_ISR() will result in this interrupt returning directly to the
unblocked task. */
portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}
An example interrupt service routine demonstrating the use of the
portYIELD_FROM_ISR() macro.
Only FreeRTOS API functions that end in "FromISR" can be called from an
interrupt service routine.
Resources used by FreeRTOS
FreeRTOS requires exclusive use of RTI channel 0, SWI instructions, and
System Software Interrupt (SSI) 0.
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 Cortex-R4 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|
