TMS320F280049: F280049 firmware update from another device

Anju,

The post you referred to is quite old, and we have made progress on our LFU solution since then. We now have an LFU reference design (TIDM-02011) and a design guide (TIDUEY4). Please refer to them.

Thanks,

Sira

Hi Sira,

Thank you for your reply.. 

can you please tell what is the main difference between the docs TIDUEY4 and spruiu9.

if we want the steps required to update the firmware in F280049 from the uart of another controller which one should we follow

Thanks 

Anju

Anju,

TIDUEY4 is a system example and is more recent. SPRUIU9 is a simple LED example and does not describe the full set of steps required to switchover from old to new firmware during LFU.

Both of the above assume a PC host is sending the LFU command to the C2000 target to perform LFU. We have reference source for this in C2000Ware in 

C2000Ware_3_04_00_00\utilities\flash_programmers\serial_flash_programmer\serial_flash_programmer

Customers typically use this as reference and implement their own solutions on whatever their host is.

Thanks,

Sira

Hi Sira,

The documents was useful.

according to the steps for the update, programming Bank0_LDFU_ROM will be working from serial_flash_programmer.exe. “1 – DFU” will takes the case 1 in the code for that in virtual studio cpp code.

 when load the application code buck_F28004x_lfuBANK1FLASH.txt it is executing serial_flash_programmer_appln.exe. “8 – Live DFU” has to be chosen.  in the code the case 8 is for Live DFU. 

is the code for serial_flash_programmer.exe and serial_flash_programmer_appln.exe is different?

Hi Sira,

I am asking this to clarify the steps from the host side for a basic update process. can you please verify?

• when ti device start in sci boot mode 
• send the kernel file 
• autobaud lock
• send the command for dfu
• send the  the Bank0_LDFU_ROM build configuration file
• Switch to Flash boot mode
• send the kernel file 
• autobaud lock
• send the command for live dfu
• send the file application code for flash bank 1
• Switch back to SCI boot mode
• when update next time use Bank1_LDFU_ROM instead of Bank0_LDFU_ROM and use application code for flash bank 0 with the same steps 
•  Reset board. Now both Flash banks will have custom bootloaders and Application Images
• from next update onwards one of the banks will update 

right?

Thanks 

Anju

Hi Sira,

Thank you for your reply and confirming the same.

so for live dfu the steps will be

• send kernel file
• auto baud check
• command for live dfu
• send the application image

do we need to send this kernel image each time of updating procedure?

Thanks 

Anju

Anju,

No, you would not need to send the kernel image during Live DFU. The kernel image is still specified as an argument in the command, but it is not used or downloaded to the target.

Thanks,

Sira

Hi sira, 

during programming for the first time , means in production time also kernel image is not using?

Thanks 

Anju

Anju,

In production, you can program the Flash kernel on Bank0, then the Application on Bank1 (through the Kernel on Bank0). Then the Flash kernel on Bank1, then the application on Bank0 (through the Kernel on Bank1).

Thanks,

Sira

HI Sira,

As per the buck example given in the document we were not able to build for Bank1_Flash for the buck_F28004x_lfu project. bank0 has been build succesfully.

fatal error: cannot open "C:\\Users\\Anju" for input

gmake: *** [libraries/sfra/sfra_gui_scicomms_driverlib.obj] Error 1
gmake: Target 'all' not remade because of errors.

can you please help

Anju