The DCAN 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 > dcan_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 dcan_flash_programmer folder. For a more detailed explanation on kernel functionality, refer to the CAN Flash Programming of C2000 Microcontrollers application note [16].

The following devices are supported by the dcan_flash_programmer in C2000Ware:

1. F28003x
2. F280015x
3. F28P65x

DCAN Flash Kernel is based off DCAN ROM loader sources. To enable this code to erase and program flash, flash APIs must be incorporated, which is done by linking the flash APIs.

Before any application data is received, the F28P65x and F280015x DCAN flash kernels erase the flash of the device readying for programming. The F28P65x and F280015x DCAN flash kernel projects allow the user to specify which flash banks and flash sectors to erase before the application is programmed. This is discussed in more detail in the CAN Flash Programming of C2000 Microcontrollers application note [16].

After the appropriate locations in flash memory are erased, the application load begins. A buffer is used to hold the received contiguous blocks of application code. When the buffer is full or a new block of non-contiguous data is detected, the code in the buffer is programmed. This continues until the entire application is received.

Before writing to a sector for the first time, the F28003x DCAN flash kernel checks to see if the sector has been erased. If the sector has not been erased, then the F28003x Flash kernel has the Flash API execute an erase operation. After this, a buffer is filled up with content to be written into Flash, and 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.

After the DCAN module is initialized in the flash kernel, this module waits for the host to send in the firmware image. The flash kernel receives 8 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.

• F28P65x and F280015x DCAN flash kernel projects support 512-bit programming
  • If desired, there is also a 128-bit programming project available for the F28P65x devices
  • The F280015x flash API supports 128-bit programming, but the flash kernel was implemented using 512-bit programming
• F28003x DCAN flash kernel project supports 128-bit programming

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

• If programming 128-bits at once (F28003x), 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, and after each mapping, an ALIGN(8) directive needs to be added to verify the 128-bit alignment.
• If programming 512-bits at once (F280015x and F28P65x), 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, and 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.

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 DCAN 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 boot option 0x02 needs to be configured.

Figure 4-19 F280039C LaunchPad CAN Transceiver and Connector Schematic

1. Find the DCAN flash kernel project for the intended device in C2000Ware and import into CCS. For example, the DCAN 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 DCAN flash kernel project is set to RAM, since the kernel needs to be linked for execution in the RAM.
3. If using a LaunchPad, then apply 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-20 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 in the flash kernel 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. In DCAN_boot.c, confirm that the local copy of bootloader_can_timing.h is included on line 64 instead of the auto-generated header file found in the include folder.
   
   
   Figure 4-21 Including the Local CAN Timing Header File
6. In bootloader_can_timing.h, confirm lines 51-53 defines the following CAN timing settings:
   1. 1Mbps bitrate
   2. 20Mhz CAN clock
   3. 20ms bit time
      
      
      Figure 4-22 Confirming the CAN Timing Settings
7. 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 DCAN 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-23 Generating the DCAN kernel txt output
8. Open the flash kernel txt file in a text editor and change bytes 3-4 to be C0 7A. These bytes contain metadata to configure the bitrate of the CAN bus.
9. 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 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 dcan_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 boot mode. If the user needs to load code from an external host in the on-chip flash, then users can either use the default BMSPs, if supported, to configure CAN boot or configure the BOOTPIN-CONFIG and BOOTDEF registers.

The default BMSPs to enable CAN boot can be found in the TMS320F28003x Real-Time Microcontrollers data sheet. If the user sets GPIO24 to 1 and GPIO32 to 0, then the boot ROM jumps to the CAN bootloader with CANRXA to GPIO5 and CANTXA to GPIO4 without needing to program the device registers.

However, if the user wants the flexibility of using CAN 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 in the TMS320F28003x Real-Time Microcontrollers data sheet to find which CAN 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-24 Setting the CAN Routing Switch
   Note: For controlCards, a custom designed CAN transceiver board and the HSEC-180-pin controlCard Docking Station needs to be used. The custom-designed transceiver board is connected to the controlCard using four connections: ground, 3.3V, CANTX and CANRX.

Now, the device needs to be set up to emulate a CAN boot with boot option 0x02, CANRXA = GPIO5 and CANTXA = GPIO4. There is only ≃10 second timeout window to send the first CAN frame to device.

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

   

   
   Figure 4-25 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 manually launch by right clicking.
      
      

      

      
      Figure 4-26 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-27 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-28 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 CAN boot with CANRXA = GPIO5 and CANTXA = GPIO4, so all BMSPs need to disabled and the EMU-BOOTDEF-LOW needs to be set to 0x02 in the lowest index. If the boot option is programmed in 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 0x0002.
      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-29 Emulating a Zero-pin CAN 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 Section 5.3 to load the boot ROM symbols. Afterwards, confirm that the device is in CAN boot.

Now, the CAN bootloader (with GPIO assignments as specified by the boot option 0x02) in the ROM begins executing and waits 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 > dcan_flash_programmer).

The host is responsible for sending the DCAN 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 frames on the CAN analyzer.

On the F28003x device, the clock to the CAN 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 100Kbps. The host CAN programmer configures the PEAK CAN analyzer to have the same clock and nominal bit rate value.

The host initializes the analyzer for CAN usage, sends the kernel over in 2-byte increments, and then sends over the image in 8-byte increments with a delay of 10ms 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 CAN 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 are detailed in [4].

dcan_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 > dcan_flash_programmer).
2. Open a terminal and run the executable dcan_flash_programmer with the following command:

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

This first loads the DCAN flash kernel into RAM of the device using the bootloader. The bytes transferred over the CAN 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-30 and Figure 4-31. The kernel branches to the application and begins executing if successfully loaded into the flash.

Figure 4-30 DCAN Flash Programmer Kernel Loaded

Figure 4-31 DCAN Flash Programmer Application Loaded