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.
See also the FAQ My application does not run, what could be wrong?
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:
main_blinky() creates one queue, and two tasks. It then starts the RTOS scheduler.
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 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.
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:
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.
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.
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.
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 );
}
Only FreeRTOS API functions that end in "FromISR" can be called from an interrupt service routine.