Kernel Configuration

A TI-RTOS application configures the TI-RTOS kernel using a configuration (.cfg file) that is found within the project. In IAR and CCS projects, this file is found in the application project workspace under the TOOLS folder.

The configuration is accomplished by selectively including or using RTSC modules available to the kernel. To use a module, the .cfg calls xdc.useModule() after which it can set various options as defined in the TI-RTOS Kernel (SYS/BIOS) User’s Guide.

Some of the option that can be configured in the .cfg file include but are not limited to:

  • Boot options

  • Number of Hwi, Swi, and Task priorities

  • Exception and Error handling

  • The duration of a System tick (the most fundamental unit of time in the TI-RTOS kernel).

  • Defining the application’s entry point and interrupt vector

  • TI-RTOS heaps and stacks

  • Including pre-compiled kernel and TI-RTOS driver libraries

  • System providers (for System_printf())

Whenever a change in the .cfg file is made, you will rerun the XDCTools’ configuro tool. This step is already handled for you as a pre-build step in the provided IAR and CCS examples.

For the CC13xx or CC26xx, a TI-RTOS kernel exists in ROM. Typically for flash footprint savings, the .cfg will include the kernel’s ROM module as shown in Listing 1.

Listing 1. How to include the TI-RTOS kernel in ROM
/* ================ ROM configuration ================ */
/*
 * To use BIOS in flash, comment out the code block below.
 */
var ROM = xdc.useModule('ti.sysbios.rom.ROM');
if (Program.cpu.deviceName.match(/CC26X2/)) {
    ROM.romName = ROM.CC26X2;
}
else if (Program.cpu.deviceName.match(/CC13X2/)) {
    ROM.romName = ROM.CC13X2;
}

The TI-RTOS kernel in ROM is optimized for performance. If additional instrumentation is required in your application (typically for debugging), you must include the TI-RTOS kernel in flash which will increase flash memory consumption. Shown below is a short list of requirements to use the TI-RTOS kernel in ROM.

  • BIOS.assertsEnabled must be set to false

  • BIOS.logsEnabled must be set to false

  • BIOS.taskEnabled must be set to true

  • BIOS.swiEnabled must be set to true

  • BIOS.runtimeCreatesEnabled must be set to true

  • BIOS must use the ti.sysbios.gates.GateMutex module

  • Clock.tickSource must be set to Clock.TickSource_TIMER

  • Semaphore.supportsPriority must be false

  • Swi, Task, and Hwi hooks are not permitted

  • Swi, Task, and Hwi name instances are not permitted

  • Task stack checking is disabled

  • Hwi.disablePriority must be set to 0x20

  • Hwi.dispatcherAutoNestingSupport must be set to true

For additional documentation in regards to the list described above, see the TI-RTOS Kernel (SYS/BIOS) User’s Guide.

Creating vs. Constructing

Most TI-RTOS modules commonly have _create() and _construct() APIs to initialize primitive instances. The main runtime differences between the two APIs are memory allocation and error handling.

Create APIs perform a memory allocation from the default TI-RTOS heap before initialization. As a result, the application must check the return value for a valid handle before continuing.

Listing 2. Creating a Semaphore
 1Semaphore_Handle sem;
 2Semaphore_Params semParams;
 3
 4Semaphore_Params_init(&semParams);
 5sem = Semaphore_create(0, &semParams, NULL); /* Memory allocated in here */
 6
 7if (sem == NULL) /* Check if the handle is valid */
 8{
 9    System_abort("Semaphore could not be created");
10}

Construct APIs are given a data structure with which to store the instance’s variables. As the memory has been pre-allocated for the instance, error checking may not be required after constructing.

Listing 3. Constructing a Semaphore
1Semaphore_Handle sem;
2Semaphore_Params semParams;
3Semaphore_Struct structSem; /* Memory allocated at build time */
4
5Semaphore_Params_init(&semParams);
6Semaphore_construct(&structSem, 0, &semParams);
7
8/* It's optional to store the handle */
9sem = Semaphore_handle(&structSem);