The SCI flash kernel is based on the ROM bootloader, communicating with the host PC application provided in C2000Ware (C2000Ware_x_xx_xx_xx > utilities > flash_programmers > serial_flash_programmer) and providing feedback to the host on the receiving of packets and completion of commands given.

Flash kernel source and project files for CCS are provided in C2000Ware, in the examples directory of the corresponding device. These projects have a post-build step in which the compiled and linked .out file is converted into the correct boot hex format needed by the SCI ROM bootloader and is saved as the project name with a .txt extension.

1. Find the SCI flash kernel project for the intended device in C2000Ware and import into CCS.

   Device	Build Configurations	Location
   F2802x	RAM	C2000Ware_x_xx_xx_xx > device_support > f2802x > examples > structs > f28027_flash_kernel
   F2803x	RAM	C2000Ware_x_xx_xx_xx > device_support > f2803x > examples > c28 > f2803x_flash_kernel
   F2805x	RAM	C2000Ware_x_xx_xx_xx > device_support > f2805x > examples > c28 > f28055_flash_kernel
   F2806x	RAM	C2000Ware_x_xx_xx_xx > device_support > f2806x > examples > c28 > f28069_sci_flash_kernel
   F2807x	RAM	C2000Ware_x_xx_xx_xx > device_support> f2807x > examples > cpu1 > F2807x_sci_flash_kernel
   F2833x	RAM	C2000Ware_x_xx_xx_xx > device_support > f2833x > examples > f28335_flash_kernel
   F2837xS	RAM	C2000Ware_x_xx_xx_xx > device_support > f2837xs > examples > cpu1 > F2837xS_sci_flash_kernel > cpu01
   F2837xD	RAM	C2000Ware_x_xx_xx_xx > device_support > f2837xd > examples > dual > F2837xD_sci_flash_kernels
   F28004x	RAM, Flash with LDFU, Flash without LDFU	C2000Ware_x_xx_xx_xx > driverlib > f28004x > examples > flash, select flashapi_ex2_sci_kernel
   F2838x	RAM	CPU1-CPU2 C2000Ware_x_x_xx_xx > driverlib > f2838x>examples>c28x_dual>flash_kernel CPU1-CM C2000Ware_x_x_xx_xx > driverlib > f2838x>examples>c28x_cm>flash_kernel
   F28002x	RAM, Flash with LDFU	C2000Ware_x_xx_xx_xx > driverlib > f28002x > examples > flash, select flash_kernel_ex3_sci_flash_kernel
   F28003x	RAM, Flash with LDFU	C2000Ware_x_xx_xx_xx > driverlib > f28003x > examples > flash, select flash_kernel_ex3_sci_flash_kernel
   F280013x	RAM	C2000Ware_x_xx_xx_xx > driverlib > f280013x > examples > flash, select flash_kernel_ex3_sci_flash_kernel
   F280015x	RAM	C2000Ware_x_xx_xx_xx > driverlib > f280015x > examples > flash, select flash_kernel_ex3_sci_flash_kernel
   F28P65x	RAM	C2000Ware_x_xx_xx_xx > driverlib > f28p65x > examples > c28x_dual > flash_kernel
   F28P55x	RAM	C2000Ware_x_xx_xx_xx > driverlib > f28p55x > examples > flash, select f28p55x_flash_ex3_sci_flash_kernel

2. Make sure that the Active Build Target Configuration of the SCI flash kernel project is set to RAM because the kernel needs to be linked for execution in the RAM.
3. Build the kernel project. These projects have a post-build step in which the compiled and linked .out file is converted into the correct boot hex format needed by the SCI ROM bootloader and is saved as the example name with a txt extension.
   1. If txt output is not generated, then follow Section 4.1 to make sure that the correct post-build step to generate the hex file is defined.
      
      
      Figure 4-7 Finding the Converted SCI Kernel Output File
4. Repeat the build process for the firmware code that is loaded into the flash by the kernel.
   1. Confirm that the Active Build Target Configuration is set for the Flash.
   2. Confirm that the correct post-build step to generate the txt file is defined.
   3. Build the firmware project.

After building the kernel and firmware projects in CCS, set up the device hardware correctly to communicate with the host PC running the serial_flash_programmer executable provided in C2000Ware. The first task is to make sure the boot mode select pins are configured properly to boot the device to SCI boot mode. If the user needs to load code from an external host in the on-chip flash, then the default BMSPs or BOOTPIN-CONFIG and BOOTDEF registers can configure SCI boot.

The default BMSPs to enable SCI boot can be found in the TMS320F280015x Real-Time Microcontrollers data sheet. If the user sets GPIO24 to 0 and GPIO32 to 1, then the boot ROM jumps to the SCI bootloader with SCIRXDA to GPIO28 and SCITXDA to GPIO29 without needing to program the device registers.

However, if the user wants the flexibility of using SCI boot with different GPIO assignments, then the OTP or emulation BOOTCONFIG and BOOTDEF registers need to be configured for the specific boot option. Refer to the GPIO Assignments section in the data sheet to find which SCI boot option fits the GPIO requirements.

When using the serial_flash_programmer executable, the appropriate SCI bootloader GPIO pins to the Rx and Tx pins need to be connected to the host PC COM port. A transceiver is often needed to convert a Virtual COM port from the PC to GPIO pins that can connect to the device. On some systems, like the controlCARD or LaunchPad, an FTDI chip is used to interface the GPIO pins used for SCI communication to a USB Virtual COM port.

For the F2800157 LaunchPad, the PC must connect to the USB on the LaunchPad and use the UART routing on the device to connect to the GPIO pins to the XDS110 COM Port. The schematics for the UART routing can be found in C2000Ware_x_xx_xx_xx > boards > (LaunchPads or controlCARDs) > DEVICE_NAME > Rev# > documentation. For F2800157, SCIRXDA is internally routed to GPIO28 and SCITXDA to GPIO29 using the default SCI_SEL settings, so boot option 0x01 needs to be configured.

Figure 4-8 F2800157 LaunchPad UART Routing Schematic

However, users can also elect to use jumpers to externally route the XDS110 COM port to the GPIO BoosterPack™ (BP) header. This is helpful if alternative SCI GPIO assignments are selected and a connection to the XDS COM port is required. The steps below demonstrate how to externally route the XDS110 COM port to GPIO28 or GPIO29 on the F2800157 LaunchPad.

1. Make sure the UART routing is set to connect to BoosterPack™ (BP) for GPIO28 and GPIO29 (SCI_Sel1 = 1); not internally to the XDS110 COM port. This allows the SCI-A signals to output in the BP header pins.
   
   
   Figure 4-9 Routing the SCI TX or RX (GPIO28 or GPIO29) Signals to the BoosterPack (BP) Pins
2. Remove the jumpers for the TXD and RXD pins on the J101 header. Note that the XDS RXD pin (closer to the XDS circuit) is connected to the MCU TXD, and is the pin closer to the XDS circuit. Similarly, the XDS TXD is connected to the MCU RXD.
3. Attach a jumper wire from XDS TXD to GPIO28 (SCI-A RX) and a jumper wire from the XDS RXD to GPIO 29 (SCI-A TXD) according to the XDS110 Target Interface section in the board schematic.
   
   
   Figure 4-10 Jumping the XDS TX, RX to the SCI TX, RX GPIOs

Now, the device needs to be set up to emulate a zero-pin SCI boot with boot option 0x01, SCIRXA = GPIO28 and SCITXA = GPIO29.

1. Open CCS to a workspace.
2. Select View > Target Configurations.
   
   

   

   
   Figure 4-11 Opening the Target Configuration Menu in CCS
3. Users can import a project for this device to CCS and use that to connect to the device, or copy the target configuration file (.ccxml) from C2000Ware (C2000Ware_x_xx_xx_xx > device_support > DEVICE_FAMILY > common > targetConfigs) to the User Defined target configurations.
   1. Find the device target config and then manually launch by right-clicking.
      
      

      

      
      Figure 4-12 Launching a Target Configuration in CCS
4. When CCS brings up the debug window, select the intended CPU and connect to the target.
   
   

   

   
   Figure 4-13 Connecting to the Target Core in CCS
5. If a window pops up stating there is a break in the boot ROM with no debug information available, or outside of program code, then follow Section 5.3 to debug the boot ROM.
6. Once the symbols are loaded, open the memory browser by going to View > Memory Browser.
   
   
   Figure 4-14 Navigating to the Memory Browser in CCS
7. In the memory browser tab, navigate to address 0xD00. Recall that the 0xD00 location specifies the BMSPs with the validity key (EMU-BOOTPIN-CONFIG) and 0xD04-0xD05 specifies the boot definitions (EMU-BOOTDEF-LOW).
8. The objective is to configure a zero-pin SCI boot with SCIRXDA to GPIO28 and SCITXDA to GPIO29, so all BMSPs need to disabled and the EMU-BOOTDEF-LOW needs to be set to 0x01 in the lowest index. If the boot option is programmed to any other entry in EMU-BOOTDEF-LOW, then the intended boot mode is not selected.
   1. Set 0xD00-0xD01 (EMU-BOOTPIN-CONFIG) to 0x5AFF FFFF.
   2. Set 0xD04 (EMU-BOOTDEF-LOW) to 0x0001.
      Note: Zero-pin boot means that the device automatically boots to the first entry defined the BOOTDEF table. This is achieved by disabling all BMSPs, thus allowing the device to only consider one boot option.

      
      
      Figure 4-15 Emulating a Zero-pin SCI Boot with SCIRXDA to GPIO28 and SCITXDA to GPIO29
9. Reset the CPU and perform an external reset (XRSn). Then, click on Resume to begin the boot sequence.
10. If there is a break in the boot ROM with no debug information available, or outside of program code, then follow the Section 5.3 to load the boot ROM symbols. Afterwards, confirm that the device is in SCI autobaud lock.

Now, the SCI bootloader (with GPIO assignments as specified by the boot option 0x01) in the ROM begins executing and waits to autobaud lock with the host (for the A character to be received to determine the baud rate at which the communications occurs). At this point, the device is ready to receive code from the host.

The command line PC utility is a programming design that can easily be incorporated into scripting environments for applications like production line programming. This was written using Microsoft Visual Studio® in C++. The project and source can be found in C2000Ware (C2000Ware_x_xx_xx_xx > utilities > flash_programmers > serial_flash_programmer).

To use this tool to program the C2000 device, make sure that the target board has been reset and is currently in the SCI boot mode as configured above, and connected to the PC COM port. The command line usage of the tool for a single core SCI boot is described below, where -d, -k, -a, -p are mandatory parameters. If the baud rate is omitted, then the baud rate is set to 9600 by default. More details on the parameters of the utility is detailed in [12].

serial_flash_programmer.exe –d DEVICE -k KERNEL_FILE -a APPLICATION_FILE -p COM# -b BAUDRATE -v

1. Find the XDS110 UART COM port by navigating to the Device Manager > Ports (COM & LP).
   
   
   Figure 4-16 Finding the XDS COM Port in Device Manager
2. Navigate to the folder containing the compiled serial_flash_programmer executable (C2000Ware_x_xx_xx_xx > utilities > flash_programmers > serial_flash_programmer). Run the executable serial_flash_programmer.exe with the following command.

   serial_flash_programmer.exe –d DEVICE_NAME –k <path_to_kernel_hex> -a <path_to_application_hex> -p COM# -v

This automatically connects to the device, perform an auto baud lock, and download the CPU1 kernel into RAM and execute. Now, the CPU1 kernel is running and waiting for a packet from the host.

1. The serial_flash_programmer prints the options to the screen to choose from that is sent to the device kernel. Select 1-DFU CPU1 to flash the application to CPU1. In this case, the original command already specified the application file, so no additional information is required at this point.
   
   
   Figure 4-17 Commanding the Serial Flash Programmer to Download the Application
2. After the execution of the command, the application needs to be executed. To run the application, select 6-Run CPU1 and specify branch address 0x0008 0000 (flash entry point of application). The application that was successfully SCI boot loaded onto the device now executes the application loaded in flash.
   
   
   Figure 4-18 Running the Application After Loading the Application into Flash