TMS320F28377S: Firmware update using CAN interface.

Hi Asad,

Related application note: CAN Flash Programming of C2000 Microcontrollers

1) We have examples available for the F28003x, F280015x, and F28P65x device currently. The main changes you will have to make is to create the DCAN Flash kernel for this device (can look to the SCI Flash Kernel for reference as a basis, and the F28003x DCAN Flash kernel for necessary functions) and use the Flash API Library provided for the F28377S device.

2) The host application can be used for the F28377S device, but may need to be modified for user device input (F28377x instead of F28003x)and device sleep time variable (time needed in ms for the F28377S Flash API to write data gathered by the DCAN Flash kernel to flash memory).

Thanks and regards,
Charles

Thank you Charles Roberson for the guidance. Regarding point number 1, I have a question: Do you recommend modifying the DCAN Flash Kernel project of 28003x for 28377S or shall we modify the SCI Flash kernel project of TMS320F28377S with CAN functions?.

I recommend modifying the SCI Flash kernel project of TMS320F28377S with CAN functions because it already has the libraries behind it specific for that device. 

Thanks,

Charles

We want to confirm some points while we are investigating and implementing  the CAN firmware update process.
1- We have a TMS320F2837x launchpad. We had like to test the CAN firmware update using this board but it appears that it is not possible since the CAN boot requires either GPIO70/71 or GPIO62/63 for CAN RX/TX. Please confirm if this is the correct understanding or there exist some other possibility?.
2-  To boot from CAN it will be required to set the boot mode pins for  GET/FLASH mode?. 
3- The BMODE value needs to be 0x07 in case of CAN BOOT0 or 0x87 in case of CAN BOOT1. We have a question in this regard. If we configure the OTP for BMODE to CAN then how do we boot from FLASH after the firmware is updated?. Will it not always jump to CAN boot on device reset?. Does it require any command on the CAN interface to boot from FLASH?. If this is the case then does it mean that the DSP can never boot to FLASH in stand alone mode (requiring some command on the CAN interface from another device to boot from FLAH)?.

Hi Asad,

1. Correct. The CAN transceiver on the LaunchPad is connected to GPIO 12 and 17, which is not one of the combinations used by CAN boot,

2. Yes, you will have to modify the BOOTCTRL register to have the device enter CAN boot. For testing purposes, you can use Emulation Boot mode instead of modifying OTP.

3. Please review this thread, I believe it answers your question.

Kind regards,

Skyler

Skyler Baumer: Thank you very much for answering. I am still unable to understand the process of booting from FLASH when BMODE is set to boot from CAN. I have gone through the thread that you have mentioned but cannot find the answer. I will appreciate if you could explain this in detail.

Charles Roberson : We have modified the F2837xS_sci_flash_kernel project with the following changes to convert it to CAN flash kernel:

1- Copied DCAN_Boot.c file from "C:\ti\C2000Ware_5_02_00_00\libraries\boot_rom\f2837xs\revB\rom_sources\F2837x_bootROM\cpu01-bootROM\source" into the        project as it contains necessary initializations for the CAN & APIs for reading data from CAN. However the following two modifications were done:
  i- commenting out the following code section:

//	entryAddr = TI_OTP_C1BROM_ESCAPE_POINT_9;
//	if((entryAddr != 0xFFFFFFFF) &&
//		   (entryAddr != 0x00000000))
//	{
//	   /*if OTP is programmed, then call OTP function*/
//	   ((void (*)(void))entryAddr)();
//	}
//
//	//Send two test frames if the OTP says so
//	if (bootMode & DCAN_BOOT_SENDTEST)
//	{
//		DCAN_SendWordData(0x0320);
//		DCAN_SendWordData(0x2837);
//	}

This was done as the T1_OTP_C1BROM_ESCAPE_POINT_9 could not be resolved and we think that it might not be necessary. Please advise.

ii- The following macro was defined as compiler could not resolve DcanaRegs: 

#define DcanaRegs CanaRegs

2- In the main() function the call to SCI_GetFunction() is replaced by call to DCAN_Boot(). 

3- The following two files are excluded from the project as these were specific for the SCI interface.

    i- SCI_Boot.c

    ii- SCI_GetFunction.c

The project folder is attached for review. It will be highly appreciated if you or any other TI expert can check it and give us a go head to start with this CAN flash kernel.F2837xS_can_flash_kernel.rar

Hi Asad,

If you plan to use CAN boot, you can modify the BOOTCTRL register to allow this, but flash boot won't be available anymore. If you want to preserve the option to boot to flash, you can write a custom bootloader that is stored in flash memory. Thus, when you set the boot mode select pins to boot to flash, you can have it run the custom bootloader that sets up CAN boot. You can add some logic in this custom bootloader to program/execute newly received CAN data or boot to an application stored in another location of flash memory. Either way, you will have to have GPIO72 == GPIO 84 == 1.

Kind regards,

Skyler

Hi Skyler Baumer,

 I am sorry that I might not have stated the query clearly. Let me rephrase it again in detail:

• Our application will be residing in FLASH and during normal operation we would like the DSP to execute this application on power reset.
• We have another System On Chip  (SOC) that communicates with the DSP on the CAN interface. This single board computer will have internet access and can download new application for the DSP when required.
• This SOC has a CAN interface with the DSP so we would like that the new application be transferred to the DSP FLASH using the CAN interface. Once the new application is written in the FLASH then DSP should be able to execute it from the FLASH.

In our older design we had SCI interface with the DSP. In that case we simply invoked the SCI bootloader (with boot mode pins selected for SCI) when new application needed to be transferred. After writing the new application to the FLASH (via the flash kernel) we changed the bootmode again to FLASH (and reset the DSP) so it  executed the new application. Since SCI bootloader is very reliable and residing in ROM so we can always recover the system if there was any bad application written or if the process got interrupted before completion. We were expecting that the CAN firmware update will be similar. 

If we write a custom bootloader residing in FLASH then it can bring the following two shortcomings:

1- If bootloader gets erased due to any reason or has some bug then it can be possible that the new application write becomes impossible without manual flashing again.
2- Uploading a custom bootloader to each DSP before shipment will add another manual process to the assembly line.

A very basic point that I am missing is: What is the actual utility of the CAN bootloader residing in ROM if we can re-program an application in FLASH  through it but then we are unable to execute this application?