CC32xx ROM services

Table of Contents

The CC32xx ROM hosts the bootloader and peripheral driver library. The peripheral driver library is a collection of routines that abstracts the peripheral programming. This library is provided in the ROM to give the developer an option to reduce the RAM footprint of the application. The peripheral driver library (driverlib) inside ROM corresponds to driverlib version Bootloader services let the user update the application binary image, along with other user files in serial flash, and are responsible for loading the user application from the serial flash to MCU RAM.

CC32xx Bootloader

The CC32xx bootloader resides in the ROM of the application processor. It is responsible for the following operations:

Update and Download
The bootloader enables the developer to download an application image from the PC to the CC32xx device (in serial flash). The bootloader-download functionality can be triggered only when the board is in UARTLOAD sense-on-power (SOP) mode.

The bootloader is also responsible for scanning a valid application image (binary) in the serial flash (for the CC32xx device). Subsequently, the image is loaded to internal RAM, and execution control is passed to the user program.

Bootloader Modes – Impact of Device SOP Pin

The CC32xx device has three SOP pins. A detailed explanation of the functionality is described in the CC32xx data sheet (SWAS035). In the context of the bootloader, there are three modes:

Download only
This mode corresponds to the SOP [2:0] being 0b100, and makes the bootloader enter the download mode. This mode expects a break signal on UART from the programming application, which is followed by a sequence to the application image to the serial flash of the device.

The SOP [2:0] setting for this case would be 0b010. The user can download the application and execute it in this mode.

A setting corresponding to SOP [2:0] = 0b000. For the CC3220/CC32xxS, this instructs the bootloader to load the application image from the SFLASH to internal MCU RAM. For the CC32xxSF, the bootloader jumps to the application image in the on-chip flash, and executes.


An SOP setting of 010 or 100 is needed for image programming through UART. 
During development and debugging, these SOP modes can be used. 
However, once the programming is done and before putting the device to final production use case, TI recommends using SOP mode 000.
The limitations and workarounds if in SOP mode 010 or 100 are listed below.
For the CC32xx device, if the SOP is configured as 010 or 100, the following scenarios may occur:
• Host requests Restore to factory feature.
• If a device reset occurs while Restore to factory is underway, the device could get into a stuck state.
1. Set the SOP to 000.
2. POR the device, and the Restore to factory is completed successfully

Bootloader / User Application – Sharing MCU RAM

The bootloader uses a portion of the MCU RAM for its own execution. The amount of RAM used by the bootloader is 16KB. This implies that for the CC3220/CC32xxS variant, the user application image must be restricted to 240KB for the 256-KB MCU RAM variant of the CC3220/CC32xxS. For the CC32xxSF variant, the application image resides in the on-chip flash, and the whole SRAM is available for the application. There are several key points for the developer when working with the CC3220/CC32xxS variant

CC32xx Peripheral Driver Library Services in ROM

Peripheral driver routines are provided in the CC32xx MCU ROM. The source for these routines, along with their project files, are also available in the CC32xx SDK as a library (driverlib). The developer can choose to link their application to the either of these routines.

This section focuses on how to use these routines, and the procedure to patch or extend any existing routines. TI recommends using these routines from ROM, because this saves the RAM space. If any modification to these routines is required, the developer can make the required changes in the library and link the application to the modified library.

Peripheral Access in ROM

The ROM APIs are indexed at a fixed location in the ROM map, which allows future extensions while retaining backward compatibility. The API locations might change in the future versions of the ROM, but API tables will remain the same. Two levels of indexing are done, which means two tables in the ROM resolve to the entry point of each supported API. The main table contains one pointer per peripheral, which points to a secondary table that contains a pointer corresponding to each API associated with that peripheral.

The main table is located at address 0x0000040C in the ROM. The following table shows a small portion of the API tables in a graphical form that helps to illustrate the arrangement of the tables:

ROM_API TABLE (at 0x0000040C)
[1] = pointer to ROM_UART TABLE
[2] = pointer to ROM_TIMER TABLE
[3] = pointer to ROM_WATCHDOG TABLE
[4] = pointer to ROM_INTERRUPT TABLE
[5] = pointer to ROM_UDMA TABLE
[6] = pointer to ROM_PRCM TABLE
[7] = pointer to ROM_I2C TABLE

… …

[0] = pointer to ROM_IntEnable
[1] = pointer to ROM_IntMasterEnable
[2] = pointer to ROM_IntMasterDisable

The address of ROM_INTERRUPT TABLE is in the memory location at 0x0000041C. The address of the ROM_IntMasterEnable () function is at offset 0x4 from that table. In the function documentation, ROM_API TABLE is an array of pointers at 0x0000040C. ROM_INTERRUPT TABLE is an array of pointers at ROM_API TABLE [4]. ROM_IntMasterEnable is a function pointer at ROM_INTERRUPT TABLE [1].

Linking the User Application With ROM APIs

The following steps describe how to use ROM driverlib APIs instead of the RAM APIs. These steps apply to all relevant source and project files that use driverlib APIs.


Follow these steps for the application as well as the libraries and projects which are driverlib-dependent and used by the application. 

Include the following header files, in order, in all .c files using the driverlib APIs:

#include "rom.h" 
#include "rom_map.h"     

Add the global preprocessor define USE_CC3220_ROM_DRV_API to all project files.

Invoke all driverlib APIs by MAP_APIname instead of APIname. For example, use MAP_UARTCharPut instead of UARTCharPut. Any changes or additions should follow this approach.

Rebuild all the relevant libraries and projects.

Patching ROM APIs

Follow these steps to selectively patch the ROM driverlib APIs. “Patch” in this description means using the RAM driverlib API instead of the ROM driverlib API.

Add an entry in the file \driverlib\rom_patch.h for all APIs to be patched. For example, to patch MAP_UARTCharPut and MAP_UARTBreakCtl entries in file rom_patch.h:

#undef ROM_UARTCharPut 
#undef ROM_UARTBreakCtl

Rebuild all the relevant projects that use driverlib APIs.

Linking With RAM-Based Peripheral Driver Library

To delink all ROM driverlib APIs and use the RAM driverlib APIs, follow these steps:

  1. Remove the global preprocessor define USE_CC3220_ROM_DRV_API from all project files that use the driverlib APIs.
  2. Rebuild all the relevant projects that use driverlib APIs.