SPRAD51A December   2023  – April 2024 F29H850TU , F29H859TU-Q1 , TMS320F2800157 , TMS320F280039 , TMS320F280039-Q1 , TMS320F280039C , TMS320F280039C-Q1 , TMS320F28P659DK-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
  5. 2Programming Fundamentals
  6. 3ROM Bootloader and Hex Utility Usage
  7. 4DCAN Flash Kernel
    1. 4.1 Implementation
      1. 4.1.1 Custom Flash Bank and Sector Erase
      2. 4.1.2 Application Load
  8. 5MCAN Flash Kernel
    1. 5.1 Implementation
      1. 5.1.1 Custom Flash Bank and Sector Erase
      2. 5.1.2 Application Load
  9. 6Example Implementation
    1. 6.1 Device Setup
      1. 6.1.1 Flash Kernels
      2. 6.1.2 Hardware
    2. 6.2 Host Application: dcan_flash_programmer
      1. 6.2.1 Overview
      2. 6.2.2 Building and Running dcan_flash_programmer Using Visual Studio
      3. 6.2.3 Running dcan_flash_programmer for F28003x
      4. 6.2.4 Using the Project With DCAN Bootloader
      5. 6.2.5 Using the Project With CCS
    3. 6.3 Host Application: can_flash_programmer [MCAN]
      1. 6.3.1 Overview
      2. 6.3.2 Building and Running can_flash_programmer Using Visual Studio
      3. 6.3.3 Running can_flash_programmer for F28003x
      4. 6.3.4 Using the Project With MCAN Bootloader
      5. 6.3.5 Using the Project With CCS
    4. 6.4 Application Load: CPU2 Image
      1. 6.4.1 Combining Two Images (.txt)
  10. 7Troubleshooting
    1. 7.1 General
    2. 7.2 DCAN Boot
    3. 7.3 MCAN Boot
  11. 8References
  12. 9Revision History

Implementation

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 (not the F28003x, this is done later) DCAN flash kernels erase the flash of the device readying it for programming. The F28P65x and F280015x DCAN flash kernel projects allow the user to specify which flash banks and flash sectors should be erased before the application is programmed. This is discussed in more detail in Custom Flash Bank and Sector Erase. 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.

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. The F28P65x and F280015x DCAN flash kernel projects support 512-bit programming, while the F28003x uses 128-bit programming. If desired, there is also a 128-bit programming project available for the F28P65x device. The F280015x flash API supports 128-bit programming, but the flash kernel was implemented using 512-bit programming.

Before writing to a sector for the first time, the F28003x (not the F28P65x and F280015x, as flash is erased earlier in the process) Flash kernel checks to see if the sector has been erased, and if it has not been erased, 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.

All of the sections of the firmware image stored in flash should be aligned according to the number of bits being programmed at once. If programming 128-bits at once (F28003x and F28P65x), the sections should be 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 ensure the 128-bit alignment. If programming 512-bits at once (F280015x and F28P65x), the sections should be 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 ensure the 512-bit alignment.

The protocol used to transfer the application data has been slightly modified from the DCAN ROM loader protocol. With the original DCAN ROM loader protocol, data is transmitted two bytes per frame at 100Kbps from the host to the target device. As the data is transmitted two bytes per frame at a time to the DCAN ROM loader, this increases the total time to download the kernel or image. By modifying the data length code (DLC) per frame to 8 bytes and increasing the bitrate to 1Mbps, this allows the PC side application to send many bytes at a time through the host, substantially decreasing the latency of communications. The changes required to increase the bitrate to 1Mbps are detailed in the Application Load section.