1 Introduction

As applications grow in complexity, the capability for bug squashing, feature additions, and embedded firmware modification is increasingly essential, especially for maintaining device safety and security integrity in the field. C2000 devices accomplish an implementation of firmware updates by offering simple loading utilities in the boot ROM (factory-programmed, Read-Only Memory).

ROM loaders, often referred to as bootloaders, reside in the target device’s boot ROM and allow application code to be loaded from an external host through software. Bootloaders serve as a reliable alternative to JTAG debug probes, which require expensive and specialized hardware with direct access to the target device.

Albeit device dependent, users can select from various peripheral bootloaders as a medium to load firmware onto the target device, such as:

1. Serial Communications Interface (SCI)
2. Serial Peripheral Interface (SPI)
3. Inter-Integrated Circuit (I2C)
4. Controller Area Network (CAN)
5. Controller Area Network Flexible Data-rate (CAN-FD)
6. Universal Serial Bus (USB)
7. Parallel GPIOs

Every C2000 device has a subset of default boot modes available to be selected. However, if the user requires access to a boot mode not offered in the default boot table or the flexibility for using different GPIO assignments, the One-Time Programmable (OTP) memory must be configured. The OTP registers allow for alternate boot modes to be selected if not offered in the default boot table.

If the user opts to use a peripheral bootloader to load new code onto the device, the application image must be generated in a specific format beforehand, as described in Section 4.1. Once the application is prepared, the data transfer between the boot ROM and host device can proceed over the selected peripheral bootloader. The application code is then loaded into the on-chip RAM by the bootloader and executed.

Peripheral bootloaders are present in every C2000 device's ROM and are simple to use, but are limited to only load code into RAM. Flash kernels bridge the gap between the ROM and Flash by providing an intermediary means to write code into the Flash from the RAM, as described in Section 3.2.

However, users getting started with C2000 bootloading can fall into pitfalls that prove challenging to debug if there is a single misstep along the boot flow (see Figure 1-1 for a general design overview). There are four phases to bootloader design that this report seeks to clarify:

1. Choosing and configuring the appropriate boot mode
2. Preparing an application to be loaded onto the device through a peripheral bootloader in the boot ROM
3. Loading an application into RAM with a bootloader
4. Using a flash kernel to program the Flash