ROM bootloaders can only load code into RAM, which is why ROM bootloaders are used to load in flash kernels to allow code to be stored in the flash, as described in Section 3.2. The CAN 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 > can_flash_programmer) and providing feedback to the host on the receiving of packets and completion of commands given. The source and executable for the host application are found in the can_flash_programmer folder. For more information on kernel functionality, refer to the CAN Flash Programming of C2000 Microcontrollers application note [16].

The following devices are supported by the can_flash_programmer in C2000Ware:

1. F28003x
2. F28P55x
3. F28P65x

The flash kernel project is modeled after the MCAN ROM bootloader. This goes straight into the MCAN_Boot function which has been modified to write to Flash. The MCAN module initialization for the flash kernel is the same as the bootloader. The clock source for the MCAN module, the nominal and data bit rates, GPIO pins, and so forth, are set by the kernel on initialization according to the boot mode.

Before any application data is received, the F28P55x kernel erases the flash of the device, readying for programming. Additionally, the F28P55x MCAN flash kernel project allows the user to specify which flash banks and flash sectors to erase before the application is programmed. This is described in more detail in the Custom Flash Bank and Sector Erase section of the CAN Flash Programming of C2000 Microcontrollers application note [16].

The F28003x kernel checks each flash sector if the flash sector been erased before programming the application. If the flash sector is has not been previously erased, then the sector is erased and the application data is written.

The F28P65x kernel erases the flash at the beginning of the application download process. Erasing flash can take a few seconds. Note, that while the application load presents as failed, the flash is being erased.

After the appropriate locations in flash memory are erased, the application load begins. The flash kernel receives 64 bytes at a time from the host and places the contents into an intermediate RAM buffer. This buffer is then written into Flash in 128-bit or 512-bit increments.

• F28003x and F28P65x MCAN flash kernels write 128-bits at a time
• F28P55x MCAN flash kernel writes 512-bits at a time

After the RAM buffer is filled up with content to be written into Flash, a program command is sent from the Flash API. Once the write has occurred, the Flash kernel has the Flash API verify that the segment was written into Flash at the correct address. Once the kernel has copied everything to Flash, the project jumps to the entry address of the image.

All of the sections of the firmware image stored in flash must be aligned according to the number of bits being programmed at once.

• If programming 128-bits at once (F28003x and F28P65x), then the flash sections of the application are aligned to a 128-bit boundary. In the linker command file for the firmware image, all initialized sections need to be mapped to Flash sectors. After each mapping, an ALIGN(8) directive needs to be added to verify the 128-bit alignment.
• If programming 512-bits at once (F28P55x), then the flash sections of the application are aligned to a 512-bit boundary. In the linker command file for the firmware image, all initialized sections need to be mapped to Flash sectors. After each mapping, an ALIGN(32) directive needs to be added to verify the 512-bit alignment.
  Note: The ALIGN(x) directive inserts padding bytes until the programmed location becomes aligned on a x word boundary. For C2000, the word size is 16-bits, so 16-bit programming requires ALIGN(1), 32-bit programming requires ALIGN(2), and so on.

The protocol used to transfer the application data follows the MCAN ROM loader protocol. With the original MCAN ROM loader protocol, nominal bitrate used is 1Mbps and transmits 64 bytes per frame from the host to the target device for nominal bit timing. The data bitrate used by the protocol is 2Mbps for data bit timing.

Flash kernel source and project files for CCS are provided in C2000Ware in the corresponding examples directory of the 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 MCAN ROM bootloader and is saved as the project name with a txt extension.

The correct GPIO assignments needed for CAN routing in the LaunchPad can be confirmed by inspecting the schematics for the CAN Transceiver and Connector in C2000Ware_x_xx_xx_xx > boards > (LaunchPads or controlCARDs) > DEVICE_NAME > Rev# > documentation. On LAUNCHXL-F280039C, the transceiver RXD is internally routed to GPIO5 and TXD to GPIO4, hence BOOTDEF 0x02 needs to be configured.

Figure 4-32 F280039C LaunchPad CAN Transceiver and Connector Schematic

1. Find the MCAN flash kernel project for the intended device in C2000Ware and import into CCS. For example, the MCAN flash kernel for F28003x is found at C2000Ware_x_x_xx_xx > driverlib > f28003x > examples > flash
2. Make sure that the Active Build Target Configuration of the MCAN flash kernel project is set to RAM because the kernel needs to be linked for execution in the RAM.
3. Add the predefined symbol _LAUNCHXL_F280039C in Project Properties > CCS Build > C2000 Compiler > Predefined Symbols to use correct GPIO assignments for the LaunchPad in device.h.
   
   
   Figure 4-33 Adding a Predefined Symbol for the Correct LaunchPad CAN GPIO Assignments
4. At power-up, the device boot ROM is clocked from an on-chip 10MHz oscillator (INTOSC2). This value needs to be set as the primary internal clock source and is the default clock at reset. In device.h, uncomment and use #define USE_PLL_SRC_INTOSC on line 295. Comment out #define USE_PLL_SRC_XTAL.
5. 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 MCAN ROM bootloader and is saved as the example name with a txt extension.
   1. If txt output is not generated, then follow the steps in Section 4.1 to make sure that the correct post-build step to generate the hex file is defined.
      
      
      Figure 4-34 Generating the CAN Kernel txt Output
6. Repeat the build process for the application code that is loaded into the flash by the kernel.
   1. Confirm that the Active Build Target Configuration is set for Flash.
   2. Confirm that the correct post-build step to generate the hex file is defined.
   3. Build the firmware project.

After building the kernel and firmware projects in CCS, set up the device hardware correctly to be able to communicate with the host PC running the can_flash_programmer provided in C2000Ware. The first task to do is make sure the boot mode select pins are configured properly to boot the device to CAN-FD boot mode. If the user needs to load code from an external host in the on-chip flash, then users need to configure the BOOTPIN-CONFIG and BOOTDEF registers since this is not available as a default boot option. Refer to the GPIO Assignments in the TMS320F28003x Real-Time Microcontrollers data sheet to find which CAN-FD boot option fits the GPIO requirements.

The hardware components needed to run the examples are a C2000 device connected to a CAN transceiver and a PEAK PCAN-USB Pro FD analyzer.

1. The LaunchPad devices contain an onboard CAN transceiver. Confirm that the PEAK PCAN-USB Pro FD Analyzer is connected to the LaunchPad through the ground, CAN-Lo and CAN-Hi connections.
2. Confirm that the onboard CAN Routing switch needs to be set low (to XCVR) for the transceiver to communicate using the GPIOs.
   
   
   Figure 4-35 Setting the CAN Routing Switch
   Note: For controlCards, a custom-designed CAN transceiver board needs to be used, and the HSEC-180-pin ControlCard Docking Station. The custom-designed transceiver board is connected to the ControlCard using four connections: ground, 3.3V, CANTX and CANRX.

The device needs to be set up to emulate a zero-pin CAN boot with boot option 0x02, CANRXA = GPIO5 and CANTXA = GPIO4. Now, the device needs to be set up to emulate a zero-pin CAN-FD boot with boot option 0x08, CANRXA = GPIO5 and CANTXA = GPIO4. Note that there is only approximately 10 seconds to send the first CAN frame to device.

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

   

   
   Figure 4-36 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-37 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-38 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 the steps in 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-39 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-x0D05 specifies the boot definitions (EMU-BOOTDEF-LOW).
8. The objective is to configure a zero-pin CAN boot with CANRXA = GPIO5 and CANTXA = GPIO4, so all BMSPs need to disabled and the EMU-BOOTDEF-LOW needs to be set to 0x08 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 0x0008.
      Note: Besides the lower eight bytes in EMU-BOOTDEF-LOW, EMU-BOOTDEF-LOW and EMU-BOOTDEF-HIGH can be any set to any value as the values are ignored in zero-pin boot.

      
      
      Figure 4-40 Emulating a Zero-pin MCAN Boot with CANRXA=GPIO5 and CANTXA=GPIO4
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 steps in Section 5.3 to load the boot ROM symbols. Afterwards, confirm that the device is in CAN boot.

Now, the MCAN bootloader (with GPIO assignments as specified by the boot option 0x08) in the ROM begins executing and waits to for a CAN frame to be transmitted from the host. At this point, the device is ready to receive code from the host.

The command line PC utility is a 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 > can_flash_programmer).

The host is responsible for sending the MCAN kernel image and flash (firmware) image to the MCU. The PEAK PCAN-USB Pro FD CAN bus analyzer is used as the host. The flash programmer project is built and run on Visual Studio 2019. The host programmer uses the PCAN_Basic API from PEAK [17]. The PCAN_Basic API can be used to send and receive CAN-FD frames on the CAN analyzer.

On the F28003x device, the clock to the MCAN module is switched to the external clock source by the Boot ROM. The external clock is 20MHz in the LaunchPad and the ControlCard. The Boot ROM configures the nominal bit rate to be 1Mbps, and the data bit rate to be 2Mbps. The host CAN programmer configures the PEAK CAN analyzer to have the same clock, nominal and data bit rate values.

The host initializes the analyzer for CAN-FD usage, sends the kernel over in 64-byte increments, and sends over the image in 64-byte increments with a delay of 100ms between each frame to give the Flash API time to program the data received into Flash. Once the firmware image has been written, the host CAN programmer exits.

To use this tool to program the C2000 device, make sure that the target board has been reset and is currently in the CAN boot mode as configured above, and connected to the PEAK PCAN-USB Pro FD CAN bus analyzer. The command line usage of the tool for a single core MCAN boot is described below, where -d, -k, and -a are mandatory parameters. Verbose output can be enabled with -v. More details on the parameters of the utility is detailed in [14].

can_flash_programmer.exe –d DEVICE -k KERNEL_FILE -a APPLICATION_FILE -v

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

   can_flash_programmer.exe –d DEVICE_NAME –k <path_to_kernel_hex> -a <path_to_application_hex> -v

This loads the MCAN flash kernel into RAM of the device using the bootloader. The bytes transferred over the MCAN bus can be seen in the terminal. Then, the kernel executes and loads and programs flash with the file specified by the ‘-a’ command line argument, as seen in Figure 4-41 and Figure 4-42. The kernel branches to the application and begins executing if successfully loaded into the flash.

Figure 4-41 MCAN Flash Programmer Kernel Loaded

Figure 4-42 MCAN Flash Programmer Application Loaded