Flash Vector Table¶
This table contains the first 16 critical interrupt vectors required for the bootup process.
The location of this table is set by default via SysConfig, it defaults to address 0x00000000. At bootup time, the TI-RTOS7 kernel will run a first function to initialize the Hwi module.:
#define Hwi_resetVectorAddress_D 0x0
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-RTOS7 Kernel (SYS/BIOS) User’s 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 SysConfig
in the TI RTOS
configuration settings, 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 size is defined in the linker file as shown below:
--stack_size=1024 /* C stack is also used for ISR stack */
Dynamic Memory Allocation¶
The system uses a single heap for dynamic memory allocation. This heap is shared between TI-RTOS7, the protocol stack, and the application.
The heap configuration is configured via SysConfig inside TI-RTOS
→
BIOS
→ Default Heap Settings
. Using SysConfig, the heap can be
configured in a few ways. Regardless of the underlying heap
implementation, the APIs to access the heap are common.
TI-RTOS7 HeapMem - The most flexible heap implementation offered by the TI-RTOS7 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.TI-RTOS7 HeapMem with HeapTrack - The most flexible heap implementation offered by the TI-RTOS7 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. To enable HeapTrack, select theUse HeapTrack with system default heap
option in SysConfig.
Configuring the Heap¶
The heap configuration is configured via SysConfig inside TI-RTOS
→
BIOS
→ Default Heap Settings
.
For more information regarding configuration options, please refer to Section 7.4 Heap Implementations of the TI-RTOS7 Kernel (SYS/BIOS) User’s Guide.
Hint
When using static heap size, it’s a good idea to review the heap size thoroughly.
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.