Flash Vector Table

This table contains the first 16 critical interrupt vectors required for the bootup process. The location of this table is controlled by m3Hwi.resetVectorAddress within the TI-RTOS config file (*.cfg), it defaults to address 0x00000000. At bootup time, the TI-RTOS kernel will run a first function to initialize the Hwi module.

For more information about the vector table format, please refer to Cortex-M4 Vector Table.

For more information on the kernel boot process and first functions, please see the TI-RTOS Kernel Users Guide.

Customer Configuration (CCFG) Table

The CCFG is placed at the end of the last flash page and lets customer configure various chip and system parameters in the Customer Configuration (CCFG) table. The CCFG table is defined in ccfg.c in the provided examples. Parameters can be determined in the SysConfig (.syscfg) file through the *TI Devices → Device Configuration options. The last (sizeof(ccfg_t)) bytes of the CCFG sector are reserved by the system for the CCFG table. By default, the linker allocates the unused flash of the last flash page to the application image for code and data use.

See the CC13x2 CC26x2 SimpleLink Wireless MCU Technical Reference Manual for details on CCFG fields and related configuration options, including how to set the CCFG to disable access to internal flash memory contents.

Note

The CCFG cannot be relocated, and must reside at the end of the last page of flash. Consult the CC13x2 CC26x2 SimpleLink Wireless MCU Technical Reference Manual for more information.

Note

If SET_CCFG_ERASE_CONF_CHIP_ERASE_DIS_N is set to 0 it’s not possible to do mass erase.

RAM

There is 80 kB of RAM available in the CC13x2x1 or CC26x2x1, 144 kB in CC13x2x7 or CC26x2x7, and 40 kB in CC13x1x3 or CC26x1x3. The various sections of RAM and their associated linker files are as follows.

  • CSTACK: This the system callstack used by the C main function and HWIs. See System Stack for more information

  • RAM Reset Vector Table: This table holds entries for all supported reset vectors. It is initialized from the flash reset vector table at boot time and is used to plug interrupt table entries at runtime. See RAM Vector Table for more information.

  • ROM Reserved RAM: When building a configuration that links to code in ROM certain sections of RAM must be reserved for the static allocations performed in ROM. If the active configuration doesn’t use ROM,these sections may be used for other purposes.

  • HEAP: See Dynamic Memory Allocation for information about heaps.

For projects where the stack project builds a library:

  • Application and Stack statically allocated data: This includes any initialized and uninitialized variables used by the application or stack. (.data,.bss)

RAM Vector Table

This table is initialized at kernel boot time with the contents of the flash vector table. The location of this table is controlled by m3Hwi.vectorTableAddress within the TI-RTOS config file (*.cfg), it defaults to address 0x20000000. The VTOR register will point to this table, which allows the creation of dynamic interrupts at runtime. This table will contain entries for all 50 supported interrupts.

System Stack

As described in Tasks, each task has its own runtime stack for context switching. Another runtime stack is used by the RTOS for main(), HWIs, and SWIs. This system stack is allocated in the application linker file to be placed at the end of the RAM of the application.

For IAR, this RTOS system stack is defined by the CSTACK symbol in the .icf file:

////////////////////////////////////////////////////////////////////////////////
// Stack
define symbol STACK_SIZE            = 0x400;
define symbol STACK_START           = RAM_END + 1;
define symbol STACK_END             = STACK_START - STACK_SIZE;
//
define symbol STACK_TOP             = RAM_END + 1;
export symbol STACK_TOP;

////////////////////////////////////////////////////////////////////////////////
// Memory Placement
////////////////////////////////////////////////////////////////////////////////

//...

      // Runtime Stack
      define block CSTACK with alignment = 8, size = STACK_SIZE { section .stack };

//...

      define block END_OF_RAM with fixed order {
                                      block HEAP_END,
                                      block CSTACK
                                    };

place at end of RAM { block END_OF_RAM };

In IAR, to change the size of the CSTACK, adjust the STACK_SIZE symbol value in the linker configuration file (.icf file) of the application.

For CCS the RTOS system stack is defined by the Program.stack parameter in the RTOS configuration file (the .cfg file):

/* ================ Program configuration ================ */

// ...
Program.stack = 1024;

and placed by the linker in the RAM space of the application (.cmd file):

/* Create global constant that points to top of stack */
/* CCS: Change stack size under Project Properties */
__STACK_TOP = __stack + __STACK_SIZE;

Dynamic Memory Allocation

The system uses a single heap for dynamic memory allocation. This heap is shared between TI-RTOS, the protocol stack, and the application.

The RTOS configuration file that configures the heap depends on the project’s build configuration. The RTOS configuration file ends with .cfg, e.g. ble_release.cfg.

Using the RTOS configuration file above the heap can be configured in one of three ways. Regardless of the underlying heap implementation, the APIs to access the heap are common.

  • TI-RTOS HeapMem - The most flexible heap implementation offered by the TI-RTOS kernel. HeapMem supports creating variable sized blocks as well as freeing blocks. It is implemented by rtos_heapmem.h when using RTOS in ROM and by direct calls when using RTOS in flash. See HeapMem with TI-RTOS in ROM for details on using the HeapMem module in ROM with the stack.

  • TI-RTOS HeapMem with HeapTrack - The most flexible heap implementation offered by the TI-RTOS kernel. HeapMem supports creating variable sized blocks as well as freeing blocks. It is implemented by rtos_heaptrack.h when using RTOS in ROM and by direct calls when using RTOS in flash. On top of the functionality offered by HeapMem, HeapTrack offers additional debugging capability, at the cost of runtime performance. See HeapMem with TI-RTOS in ROM for details on using the HeapMem module in ROM with the stack.

Configuring the Heap

The active heap configuration is set via the HEAPMGR_CONFIG variable. If auto heapsizing is not used, the size of the heap is controlled via HEAPMGR_SIZE.The location of both the HEAPMGR_CONFIG and HEAPMGR_SIZE variables are dependent on the project’s current build configuration. These variables are defined in the app’s .cfg file.

The system will default to using the OSAL heap with auto heap size. The table below shows the possible configurations of the heap along with their associated values of HEAPMGR_CONFIG and HEAPMGR_SIZE.

HEAPMGR_CONFIG

Active Heap Configuration

Heap Size

0x00

OSAL HeapMgr, static heap size

Set by HEAPMGR_SIZE

0x80

OSAL HeapMgr, automatic heap size

Automatically determined by the amount of free space available at link time between heapStart and heapEnd symbols

0x01

HeapMem, static heap size

Set by HEAPMGR_SIZE

0x81

HeapMem, automatic heap size

Automatically determined by the amount of free space available at link time between heapStart and heapEnd symbols

0x02

HeapMem + HeapTrack, static heap size

Set by HEAPMGR_SIZE

0x82

HeapMem + HeapTrack, automatic heap size

Automatically determined by the amount of free space available at link time between heapStart and heapEnd symbols

Warning

If autoheap size is to be used, heapStart and heapEnd symbols must be defined in the linker file. See your application’s map file for the location of these sections in the StackLibrary configuration.

  • heapStart – Placed at end of static allocation section

  • heapEnd – Placed right before beginning of CSTACK section

See the snippet below from the app’s .cfg to see how to change the active heap configuration. Change the variable in the highlighted line to one of the values supported in the table above.

1var Memory = xdc.useModule('xdc.runtime.Memory');
2var HEAPMGR_CONFIG = 0x00;  //set to OSAL HeapMgr, static heap size
3var HEAPMGR_SIZE   = 8000; //only valid if static size is used. This is the
4                            //size of the buffer allocated for Heap.

Hint

When using static heap size, it’s a good idea to review the heap size thoroughly.

HeapMem with TI-RTOS in ROM

When using any HeapMem based configuration combined with TI-RTOS in ROM, the heap will be implemented by HeapCallback module. HeapCallback will call a user defined function whenever a dynamic memory operation is required. The user defined functions are located in the following files.

  • rtos_heapmem.h – HeapMem

  • rtos_heaptrack.h – HeapMem + HeapTrack

This is required because the HeapMem implementation in ROM uses the GateMutex module, which prevents malloc() from being called in a hwi or swi. In order to allow safe use of the heap a GateHWI must be used. To work around this, the HeapCallback implementation will wrap any access to the heap in a HWI lock. See the following example from rtos_heapmem.h.

/* Protect since HeapMem_allocUnprotected does not */
hwikey = (uint_least16_t)Hwi_disable();

/* Using the default system heap for this example */
tmp = HeapMem_allocUnprotected(stackHeap, size, FORCED_ALIGNEMENT);

// ..

/* restore the hwi mutex */
Hwi_restore(hwikey);

Note

Note that the legacy OSAL heap always protects heap operations with a HWI lock.

When using a flash based kernel, the HeapMem module is configured to use a GateHWI, see the following excerpt from ble_debug.cfg.

Program.global.stackHeap = HeapMem.create(heapMemParams);
var GateHwi = xdc.useModule('ti.sysbios.gates.GateHwi');
HeapMem.common$.gate = GateHwi.create();
Memory.defaultHeapInstance = Program.global.stackHeap;

Cache

The cache is an 8 kB section of the device’s RAM reserved for the processor. The cache module temporarily stores data that has been read from the Flash, so that frequently used data is not fetched from Flash on each access. This reduces the number of CPU wait-states and saves power. When the cache is not used, it is not powered. This is true for Standby and Idle states where the cache is not in use.

AUX RAM

The AUX RAM is a 4 kB memory area belonging to the Sensor Controller. This is not available on CC13x1x3 or CC26x1x3 devices.