The USB 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 > usb_flash_programmer) and essentially performing the same operations as the ROM bootloader. Because the ROM bootloader is equipped with the flash API, the bootloader is able to erase and program flash to perform the firmware update.

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 .dat extension.

1. Find the USB flash kernel project for the intended device in C2000Ware and import into CCS.
   1. For F2837xD devices, the kernels can be found in C2000Ware_x_xx_xx_ > device_support > f2837xD > dual > F2837xD_usb_flash_kernels.
2. Make sure that the USB flash kernel project Active Build Target Configuration is set to RAM, since the kernel needs to be linked for execution in the RAM.
   
   
   Figure 4-43 Generating the Correct USB Kernel Bin Output
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 binary format needed by the USB ROM bootloader and is saved as the example name with a .dat extension.
   Note: If .dat output is not generated, then follow the steps in Section 4.1 to verify that the correct post-build step to generate the binary file is defined.
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 Flash.
   2. Follow the steps in Section 4.1 to verify that the correct post-build step to generate the binary file is defined.
   3. Build the firmware project.

After building the kernels in CCS, set up the device correctly to communicate with the host PC running the usb_flash_programmer.

1. Connect the mini-USB and micro-USB from the controlCARD to the host PC.
2. Set controlCARD GPIOs to debug using CCS and the On-Card XDS100v2 Emulator [20]. Refer to the ROM Bootloader section in the USB Flash Programming of C2000™ Microcontrollers application report for the connectivity options.
   1. Set A:SW1 Position 1 to On (up) and Position 2 to Off (down).
   
   
   Figure 4-44 Configure the F2837xD controlCard to Debug Using CCS and the Onboard XDS Emulator
3. Open CCS to a workspace.
4. Select View > Target Configurations.
   
   

   

   
   Figure 4-45 Opening the Target Configuration Menu in CCS
5. 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-46 Launching a Target Configuration in CCS
6. When CCS brings up the debug window, select the intended CPU and connect to the target.
   
   

   

   
   Figure 4-47 Connecting to the Target Core in CCS
7. 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 the steps in Section 5.3 to debug the boot ROM.
8. Once the symbols are loaded, open the memory browser by going to View > Memory Browser.
   
   
   Figure 4-48 Navigating to the Memory Browser in CCS
9. In the memory browser tab, navigate to address 0xD00.
10. Set device up for emulation USB Boot. The BMODE value is defined as 0x0C in the Configuring Get Boot Options section of the TMS320F28003xD Real-Time Microcontrollers technical reference manual [23]. Program 0xD00 to 0x0C5A.
    
    
    Figure 4-49 Configuring the F2837xD controlCard to Emulate USB Boot
11. Reset the CPU and then click on Resume to enable the USB boot sequence.
12. If there is a break in the boot ROM with no debug information available, or outside of program code, then follow the steps in Section 5.3 to load the boot ROM symbols. Afterward, confirm that the device is in USB boot in the boot ROM.

Command line options and file IO can be done through the C standard library, but USB operations can only be done through the device driver framework of the operating system. There are two widely-used libraries that provide this capability.

The first is libusb, an open-source (LGPL) library that features a Unix-style API. The second is WinUSB, which is part of the Windows Driver Development Kit. Both libraries run in user mode and provide generic access to USB devices without the need for a customer driver. Libusb is very easy to use and is also available on Linux, but it's somewhat slower and any distribution is complicated by the license. WinUSB is harder to use, but is faster and the resulting software is simpler to distribute.

The precompiled version of usb_flash_programmer.exe included with C2000Ware uses WinUSB, but source code is provided for both libraries. The WinUSB drivers need to be installed on the device for the USB bootloader to run.

1. Go to the Device Manager and right-click on the unrecognized device under Universal Serial Bus controllers. The F28379D displays as Stellaris Device Firmware Upgrade.
2. Select Update Drivers > Browse my computer for drivers > Let me pick from a list of available drivers on my computer > Have Disk.
   1. Input this into the Copy from manufacturer’s files from: C2000Ware_x_xx_xx_xx\utilities\flash_programmers\usb_flash_programmer\windows_driver\x86
      
      
      Figure 4-50 Browsing C2000Ware for the USB Windows Drivers
3. Now, the WinUSB drivers are installed onto the device and appear as F28x7x USB Boot Loader under the Texas Instruments Microcontrollers category if done successfully.
   
   
   Figure 4-51 The F28x7x USB Boot Loader device appearing in the Device Manager
4. Reset the CPU and perform an external reset (XRSn). Then, click on Resume to begin the boot sequence.

The command line PC utility is a lightweight (approximately 64KB executable) programming solution 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 > usb_flash_programmer > src > VS2010_USBLoader2000).

Input filepaths are loaded in ascending order on the command line, so the flash kernel filepath must be provided listed first to be loaded into the RAM. After the flash kernel is loaded, the ROM transfers control and the kernel begins to execute to program the application to the flash. The flash kernel must prepare the device for flash programming before the device is ready to begin communications, so a small delay is needed. During this time, the flash kernel configures the PLL and flash wait states.

At the beginning of the download process, some preliminary data is transferred before the actual flash application code, including a key, a few reserved fields, and the application entry point. This is after the entry point is received that the kernel begins to erase the flash. Erasing the flash can take a few seconds. Note, that while the application load looks as if failed, the flash is being erased. Once the flash is erased, the application load continues by transferring each block of application code and programming to flash.

1. Navigate to the folder containing the compiled usb_flash_programmer executable (C2000Ware_x_xx_xx_xx > utilities > flash_programmers > usb_flash_programmer).
2. Open a terminal and run the executable usb_flash_programmer.exe with the following command:

   usb_flash_programmer.exe <path_to_kernel_dat> <path_to_application_dat>

   Note: Both the flash kernels and flash application MUST be in the binary boot format as discussed earlier in Section 4.1.

Once the application is programmed into flash, the flash kernel attempts to run the application by branching to the entry point that was transferred at the start of the application load process.