CCS/TMS320F28069: Boot-loader and firmware upgrade method

Hi Rajesh, 

Please provide some clarification on the terminology you are using.  What do you mean by second bootloader?  Fundamentally speaking, think of the bootloader and your main application as two somewhat independent applications.  

Going back to the basics, are you able to load the bootloader independently and does it run as you expect it to run?  Similarly are you able to load the main application independently and does it run as you expect it to run?

If you can achieve the above two things, then at a high level you simply need to place the bootloader at the boot location in Flash, confirm that it can run independently.  Once you achieve that, what you suggest in Question 3 is the right course of action.  The bootloader can be used to transmit the hex file of the main application via the CAN bus.  

On side note, what serves as a host to your target that contains the bootloader? 

Hope this helps...please let us know if you have additional questions. 

Cheers! 

Krishna

Hi Krishna ,

Thanks for getting back , and sorry for my confusing terminologies.

Please provide some clarification on the terminology you are using - The reason I used "Second bootloader"is I figured there is a default TI bootloader in the ROM so it can be confusing to call it just the boot-loader. But its basically a CAN boot-loader which will be used for Firmware upgrade( if there is a valid CAN packet reception).  But lets just call it CAN-boot loader

Yes, I have two separate CCS projects one for the CAN-boot loader and the other one for Main application. 

Although could you clarify Question 1 as to if the code_start_branch instructions & the linker .cmd file sections make sense.

Also(Question 2) is it okay to have same RAM locations assigned for .ebss .esysmem .stack & ramfuncs sections for both the CCS projects i.e. CAN-boot-loader and the Main application.

what serves as a host to your target that contains the bootloader? -  As of now , I have implemented a python script which parses the hex file in packets of 2 bytes and transmits via a CAN adapter. And if the bootloader receives 0x08AA it proceeds with bootloading and if not received it times out after a certain period of time.

Regards

Rajesh

Hi ,

I have a update, according to the instructions in the reference manual to use the eCAN bootloader, I have generated a ASCII .hex file for my main application that will be flashed into sector B . This is what it looks like(its only the first few lines of the .hex file)

AA 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3F 00 FE 3F 83 02
3F 00 29 35 FF FF 42 A1 00 00 00 00 FF FF 43 A1 00 00 00 00 FF FF 44 A1
00 00 00 00 FF FF 47 A1 00 00 00 00 FF FF 48 A1 00 00 10 27 FF FF 49 A1

But according to the Boot ROM section in the technical reference manual,  the Thirteenth and the fourteenth word( OR Byte #25,26,27,28) should be the destination address which in my case happens to be FLASH Sector B (0x3F0000). I am just confused as to why the system chose 0x3F2529(3F 00 29 35) instead of FLASH Sector B starting address 0x3F0000 ? May be I am missing something here. And just for reference this is what my .cmd linker file sections look like :

SECTIONS
{

   /* Allocate program areas: */
   .cinit              : > FLASHB,     PAGE = 0
   .pinit              : > FLASHB,     PAGE = 0
   .text               : > FLASHB,     PAGE = 0
   codestart           : > BEGIN,      PAGE = 0

   /* Allocate uninitalized data sections: */

   .stack              : > RAMM0,      PAGE = 1
   .ebss               : > RAML4,      PAGE = 1
   .esysmem            : > RAMM1,      PAGE = 1
   .scratchpad         : > RAML1,      PAGE = 1

   /* Initalized sections to go in Flash */
   /* For SDFlash to program these, they must be allocated to page 0 */
   .econst             : > FLASHC,     PAGE = 0
   .switch             : > FLASHB,     PAGE = 0
   .scratchpad           : > RAML1,       PAGE = 1

   snapshot_buffer       : > RAML78,      PAGE = 1
   /* Allocate FPU math areas: */
   FPUmathTables       : > FPUTABLES,  PAGE = 0, TYPE = NOLOAD

   ClaToCpuMsgRAM     : > CLA1_MSGRAMLOW,            PAGE = 1                /* Link to PF0 - CLA Message RAM */
   CpuToClaMsgRAM     : > CLA1_MSGRAMHIGH,            PAGE = 1                /* Link to PF0 - CLA Message RAM */


      /* Section Cla1Prog used by file Cla.c */
   Cla1Prog           :   LOAD = FLASHH, PAGE = 0                /* Load to flash, run from CLA Prog RAM */
                          RUN_START(_Cla1Prog_Start)
                          RUN = RAML3,   PAGE = 0
                          LOAD_START(_Cla1funcsLoadStart),
                          LOAD_SIZE(_Cla1funcsLoadSize),
                          RUN_START(_Cla1funcsRunStart)

   CLA1mathTables       : LOAD = FLASHC, PAGE = 1
                         RUN = RAML2,  PAGE = 1
                         LOAD_START(_CLA1mathTablesLoadStart),
                         LOAD_END(_CLA1mathTablesLoadEnd),
                         LOAD_SIZE(_CLA1mathTablesLoadSize),
                         RUN_START(_CLA1mathTablesRunStart)

   ramfuncs            : LOAD = FLASHD, PAGE = 0
                         RUN =  RAML6 , PAGE = 0
                         LOAD_START(_RamfuncsLoadStart),
                         LOAD_END(_RamfuncsLoadEnd),
                         RUN_START(_RamfuncsRunStart)


  Cla1DataRam1        : > RAML1,          PAGE = 1

  ClaToCpuDataRAM    : > RAML0,          PAGE = 1

   .reset              : > RESET,      PAGE = 0, TYPE = DSECT

   vectors             : > VECTORS,    PAGE = 0, TYPE = DSECT

}

Any kind of insight would be really appreciated.

Regards

Hi Rajesh, 

Thanks for the follow up...

Can you please clarify what you mean by this:

    I am just confused as to why the system chose 0x3F2529 instead of FLASH Sector B starting address 0x3F0000 ? 

Also please provide the names and links of documents that you are referring to.

Thanks,

Krishna

Hi Krishna,

Also please provide the names and links of documents that you are referring to.

I was referring to the "TMS320x2806x Piccolo Technical Reference Manual (Rev. H)" document.

Can you please clarify what you mean by this:

According to section 2.2.11 in the reference manual , in order to follow the structure of the data stream incoming to the bootloader one has to generate a ASCII hex file using the c2000hex utility. And as per the reference manual(Table 2-10) Byte 25-28 constitute the destination address, OR where the new firmware via bootloader will be flashed. In my case, I have decided to use FLASH Sector B for my Main application.

Here's my question : The flash Sector B starts from address 0x3F0000,technically I would expect the secondary bootloader to download the new firmware's first block of data (for my main application) to this address . Instead it happens to be 0x003F3529(referring to "3F 00 29 35" in the hex file )  . Is there a way in the C2000 hex utility to define where I want first block of data of my application to be written ? OR is there something I am missing ?

P.S : I have  set the entry point to 0x3F3FFE , for the boot loader options I have used  -boot, -gpio8

Hi Rajesh, 

When you load the application via CCS, does it load as you expect?  thanks, Krishna

Hi Krishna,

Yes I am able to successfully flash the TI Piccolo xF28069 Bootloader application(secondary bootloader) project and also debug it.

But when I initiate the firmware upgrade process,  by sending the hex data bytes through CAN , it stops after a few seconds and a message is displayed "Break at address "0x3ff4fa" with no debug information available, or outside of program code. "

And just for debug purpose I had put counter variables initialized to zero in different functions like the CAN_GetWordData() and ReadReservedFn()[ these functions are part of CAN_Boot.c file available in  TI control suite] and GetLongDataCounter().

And the numbers were correct , for ex. ReadReservedFn() counter increments to 8 which correctly represents the 8 packets of data with 0x0000. But the increment for the variable in CAN_GetWordData() is variable depending upon the bootable main application hex file. And I believe the program counter barely makes it to CopyData() , because sometimes the variable counter inside the function increments to 2 and some times doesn't change and sticks to zero

Rajesh

Hi Rajesh, 

Sorry you are running into this issue.  It will be quite challenging to help you debug this issue in the manner that we are pursuing it now.  But let us continue...you said:

>>But when I initiate the firmware upgrade process,  by sending the hex data bytes through CAN , it stops after a few seconds and a message is displayed "Break at >>address "0x3ff4fa" with no debug information available, or outside of program code. "

Does the failure occur at the same spot every time...or is it random?

Can you create a sequence diagram that describes, how the process gets initiated, which function gets called first on the target, what happens next, how do you get confirmation that the current transaction successfully completed, how do check that it completed successfully before initiating the next one? 

Block Diagrams, Sequence diagrams...will be helpful. 

Cheers!

Krishna