This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Firmware update process

Other Parts Discussed in Thread: CONTROLSUITE

Hi Folks,

I'm looking into allowing in-field updating of the firmware on an F2802x based device. I'm currently developing using a c2000 launchpad F28027.

Im trying to understand the normal process for achieving the update of firmware in the field. 

- I compile a project in CSC that produces a `.out` file. This is what needs to go onto the device.

- The boot mode of the device is selected using TRST, TDO & GPIO34

- Send the `.out` file over I2C from a PC to the device.

- Change the boot made back and run the device with the new firmware.

Is this correct process or am I way off base here?

I have seen mention of boot-loaders and changing the branch address in codestart (where is that set?) and having the firmware itself handle storing code to flash and selection of the code to run upon boot. How does this work?

I did try reading SPRUFN6, but didnt understand much of it at this point! :o

Thanks, T

PS, If I wanted to use JTAG to load the new code, does this require an XDS100 emulator?

  • Hi Toby,

    If you are using a Launchpad, you only need a USB cable from your PC running CCS and your F28027.

    What you have described is the basic boot mode procedure...
    1) Boot to specific mode so that the Peripheral Bootloader is running in Boot ROM.
    2) Convert your .out file to the appropriate hex fie using the CCS CodeGen tools or the Hex2000 utility found in controlSUITE.
    3) Send the hex file over your communications link to the C28x running the peripheral bootloader.

    See Section 2.19 and Figure 23 and Table 13 in SPRUFN6. After converting the .out file to the hex boot format needed for I2C, you can see the EntryPoint Address in Figure 23 and modify that if you wish. This will change the address the C28x will branch too after loading the file and completing the bootloader function.

    However, the peripheral bootloaders are NOT capable of erasing and programming Flash on the device. They can only load and store to RAM.

    For performing a firmware upgrade to Flash using the SCI we have provided a solution in controlSUITE. We provide the source of the Host PC code (serial_flash_programmer) and the C28x Flash kernels (f28027_flash_kernel) so they can be modified for particular use cases.

    The Flash kernel bridges the gap between using a peripheral bootloader to load to RAM and the Flash API which the CPU uses to program Flash. The peripheral bootloader loads the Flash kernel into RAM which is then executed. The Flash kernel essentially a modified bootloader equipped with the Flash API. It loads a strictly Flash application from the peripheral and erases, programs and verifies the Flash with the Flash application. We will have an App Note shortly on ti.com and I will post a link to it here for convenience.

    Best Regards,
    sal
  • Many thanks Sal, will have a read of that App Note over the weekend :)