TMS320F28388D: Boot loader Design

Please expect some delay in the response as 31-May is a TI Holiday

Hi Stevin,

Regarding your first question -

The CPU1 kernel can be written to Flash, the Flash API needs to be copied to RAM. Please refer to the linker command file in C2000Ware_3_04_00_00\driverlib\f2838x\examples\c28x\flash\flashapi_ex1_programming for an example on how to copy the Flash API to RAM for F2838x. For an example on how to write the Flash kernel to Flash, you can refer to the F28004x SCI Flash Kernel example and look at the f28004x_flash_bank0_NoLDFU_lnk.cmd or f28004x_flash_bank1_NoLDFU_lnk.cmd files.

In order to write the CPU2 or CM kernels to Flash, the linker command files of the projects would need to be modified so that the projects are placed in Flash - the Flash API still needs to be in RAM for these projects - and the boot modes that CPU1 uses to boot CPU2 and CM would need to change as well so that CPU2 and CM will boot from Flash. 

Regarding your second question -

The CPU1 CCS projects could be combined to allow booting CPU2 and CM in the same project. You would need to make sure that when you boot CPU2 or CM that CPU1 would have a way to get back control so that it can boot the other core as well. Currently, when CPU1 boots another core, it waits for the other core to finish execution before either jumping to the entry address of the application in Flash or triggering a Watchdog reset . Please make sure that you also have enough memory for the CPU1 project to allow booting both CPU2 and CM. 

You can refer to C2000Ware_3_04_00_00\driverlib\f2838x\examples\c28x\boot for an example on how to boot CPU2 and CM in the same project. 

The host side programmer would also need to be modified to allow programming CPU1, CPU2 and CM all at once. Currently, the host side programmer allows either CPU1 commands followed by CPU2 commands, or CPU1 commands followed by CM commands. You would need to modify the source code of the host side programmer to allow the programmer to switch between all 3 cores. We can start a discussion offline if you need access to the source code for the host side programmer. 

Thanks, 

Anu

Hy Anu,

 We changed the linker file , given ram functions to load flashapis to RAM. So this worked  in CPU!-CPU2 SCI kernel , but the same is not working in CPU1­-CM SCI kernel.

In this CPU1-CM SCI kernel (flash build) DFU1 (.i.e. of CPU 1 application )update is working fine without kernel loading .But when we try to load kernel of CM via IPC to CM ram , loading process gets stuck just right after the entry address opcodes every time. I will attach the linker file as well as screen shot of windows cmd window. IPC based kernel loading is getting stuck .The new flash based linker file is made from reference to ram based linker file of the same project , the sections msg_ram all has been taken care .

The only changes made to the kernel is a flash based linker file is created, and include of

memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);

to run flash api's from ram.

my guss is that as in windows cmd we are able to see key checking and read and discard of 16 byts of data , the ipc based kernel loading is not working properly as expected.

 2838x_FLASH_lnk_cpu1.zip

Thanks and regards,

Stevin

Stevin, 

CPU1 normally writes the CPU2 and CM kernels to RAM. 

The CPU1 kernel currently writes the CPU2 kernel into global shared RAM and then boots CPU2. When CPU2 goes through its boot procedure, it copies a branch function placed in CPU1 to CPU2 Message RAM into its M1RAM and then starts execution from M1RAM. The branch function takes it to the entry point of the CPU2 kernel. Just modifying the CPU2 kernel linker command file will not ensure that the kernel is actually written into Flash since the function that writes the CPU2 kernel writes to RAM. 

For the CM kernel, there is a copy function on the CPU1 side that communicates with a copy function on the CM side to transfer the kernel - CPU1 writes a block to a buffer in message RAM and sends the address that the contents of the buffer needs to be written at, and CM takes the buffer and writes it at the address that CPU1 passed. The copy function on the CM side would need to be modified to write to Flash instead of RAM. That being said, you do not need to use this copy function if you want to write to Flash, you can simply use CCS to download the CM kernel to Flash in the same manner that you do for CPU1. 

If you want to load the CPU2 and CM kernels into Flash, in addition to changing the linker command files for the CPU2 and CM projects, you need to change the boot mode that CPU1 sets for CPU2 and CM. In the flash kernel examples, the boot modes for CPU2 and CM are "IPC Message RAM copy and boot to M1RAM" and "IPC Message RAM copy and boot to S0RAM". You would need to change them to one of the Flash Boot modes depending on where you place the kernel in Flash. You can then load the kernel projects into CCS for CPU2 and CM like you do for CPU1.

You may also need to synchronize CPU2 or CM with CPU1 so that the kernels do not execute before CPU1 instructs them to do so. You can add an IPC_sync() function call at the top of the main function for the CPU2/CM kernel projects and after the boot mode for CPU2 or CM has been set in the CPU1 kernel project. 

In addition, you would need to modify the host side programmer so that it does not try to download a kernel via SCI since it is being written via CCS. Please contact the FAE you are in contact with so we can discuss sending you the host programmer source files. 

Thanks, 

Anu

Hy Anu,

I have already changed boot mode. what i am currenty trying is , Build CPU1 Sci kernel in FLASH and use serial_flash_programmer_appln_f2838x_cm.cmd  host application( which will not download cpu1 kernel into RAM, ).

Then run DFU1  which will update application in flash sector other than which kernel occupy( in CPU1 ), again use RUN_CPU1_BOOT_CM option which will download CM kernel to CM RAM as it is designed. Telling that now its CPU1 SCI kernel is only made to reside in FLASH not CM SCI kernel. For this i think only linker file modification is required in CPU1 . After changing the linker file , DFU1 is working fine using serial_flash_programmer_appln_f2838x_cm.cmd and running the application in cpu1 also happens. But when i try to use  RUN_CPU1_BOOT_CM option and download CM kernel the code is stuck as u see in the screen shot above. The msg RAM for CM is build in Flash linker file as it was given in RAM linker file. What  should i do to avoid this?

Thanks and Regards,

Stevin.

Stevin, 

Thanks for the clarification. If you are trying to download the kernel to CM RAM, you can use the original boot mode in the project. 

I tried running the F2838x CPU1 kernel project with your linker cmd file and was not able to reproduce the error you had. Where did you this line in your project? 

Stevin Martin said:

memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);

Did you add anything other than that line in your project? Also, did you add a build configuration for Flash and add "_FLASH" in the predefined symbols? 

Thanks, 

Anu

Anu ,

I have used memcpy() at the beginning of main() function only. I have not added a build configuration for flash, have used _FLASH as predefined symbol.

1.Where you able to successfully boot cm kernel using the linker file?

2.when i build a new configuration build to flash , only defining of macro _FLASH need to be done right?

I would also like to add that,

i also try to put kernel into flash using ram build kernel. Here i give FLASH build SCI kernel as Application file to SCI kernel running in RAM , this can be used when we need to put sci kernel into flash  independent of ccs . This worked for CPU1 sci kernel as well as CPU2  sci kernel. But when i try to do it CPU1 _CM Serial kernel at the middle i am getting  'PROGRAM_ERROR '.why is it so?

Thanks and regards,

Stev

Anu,

I was able to create separate flash build configuration were _FLASH and linker file is given. From debug window i came to understood where the code stuck.I will Share the ss of the debug window , the program flow is stuck within the while loop in green shade . please have a look.

Which pragma should i use above the functions which is to be loaded from flash to ram? and to which all functions should i give it?

Thanks and regards,

Stev

Stevin, 

I was able to load the CM kernel with the CPU1 Flash build SCI kernel.

There is one thing I want to confirm - are your kernel and application for CPU1 in Flash mapped to different sectors? This was one issue I was having when first using the linker command file, mapping the application to different sectors from the kernel resolved that.

The screenshot you pasted above means that CPU1 is waiting for CM to synchronize. There should be a CM copy function that synchronizes with this function. Are you connecting to CM in CCS? If not, the copy function is not going to be in CM when CPU1 reaches the function above. You need to connect to CM in CCS and click Run after you load the CPU1 kernel into the device. CM will then be waiting for its boot mode to be set, which CPU1 will do when using the "Run CPU1 Load CM" option in the kernel. 

Regarding your question about Flash build configurations, the _FLASH symbol should be sufficient for symbols. Because we are also using the Flash API, it needs to be referenced in the linker command file. Please look at the linker command file pasted in the next reply. You do not need to add the memcpy function at the beginning of the main function. The InitSysCtrl function should take care of calling that function when the _FLASH symbol is defined in the project settings for the Flash build configuration. 

Regarding pragma statements, what functions do you need to run out of RAM other than the Flash API functions? 

Regarding loading the Flash build kernels via the serial flash programmer, are you mapping all initialized sections to Flash in the linker command file? Are they aligned to 128 bit boundaries? You can use the ALIGN(8) directive in the linker command file to do that. 

Here is the linker command file: 

MEMORY
{
   /* BEGIN is used for the "boot to Flash" bootloader mode   */
   BEGIN            : origin = 0x080000, length = 0x000002
   BOOT_RSVD        : origin = 0x000002, length = 0x0001AF     /* Part of M0, BOOT rom will use this for stack */
   RAMM0            : origin = 0x0001B1, length = 0x00024F
   RAMM1            : origin = 0x000400, length = 0x0003F8     /* on-chip RAM block M1 */
//   RAMM1_RSVD       : origin = 0x0007F8, length = 0x000008     /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
   RAMD0            : origin = 0x00C000, length = 0x000800
   RAMD1            : origin = 0x00C800, length = 0x000800
   RAMLS0           : origin = 0x008000, length = 0x000800
   RAMLS1           : origin = 0x008800, length = 0x000800
   RAMLS2           : origin = 0x009000, length = 0x000800
   RAMLS3           : origin = 0x009800, length = 0x000800
   RAMLS4           : origin = 0x00A000, length = 0x000800
   RAMLS5           : origin = 0x00A800, length = 0x000800
   RAMLS6           : origin = 0x00B000, length = 0x000800
   RAMLS7           : origin = 0x00B800, length = 0x000800
   RAMGS0           : origin = 0x00D000, length = 0x001000

   RAMGS1           : origin = 0x00E000, length = 0x001000

   RAMGS2           : origin = 0x00F000, length = 0x001000
   RAMGS3           : origin = 0x010000, length = 0x001000
   RAMGS4           : origin = 0x011000, length = 0x001000
   RAMGS5           : origin = 0x012000, length = 0x001000
   RAMGS6           : origin = 0x013000, length = 0x001000
   RAMGS7           : origin = 0x014000, length = 0x001000
   RAMGS8           : origin = 0x015000, length = 0x001000
   RAMGS9           : origin = 0x016000, length = 0x001000
   RAMGS10          : origin = 0x017000, length = 0x001000
   RAMGS11          : origin = 0x018000, length = 0x001000
   RAMGS12          : origin = 0x019000, length = 0x001000
   RAMGS13          : origin = 0x01A000, length = 0x001000
   RAMGS14          : origin = 0x01B000, length = 0x001000
   RAMGS15          : origin = 0x01C000, length = 0x000FF8
//   RAMGS15_RSVD     : origin = 0x01CFF8, length = 0x000008     /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

   /* Flash sectors */
   FLASH0           : origin = 0x080002, length = 0x001FFE  /* on-chip Flash */
   FLASH1           : origin = 0x082000, length = 0x002000  /* on-chip Flash */
   FLASH2           : origin = 0x084000, length = 0x002000  /* on-chip Flash */
   FLASH3           : origin = 0x086000, length = 0x002000  /* on-chip Flash */
   FLASH4           : origin = 0x088000, length = 0x008000  /* on-chip Flash */
   FLASH5           : origin = 0x090000, length = 0x008000  /* on-chip Flash */
   FLASH6           : origin = 0x098000, length = 0x008000  /* on-chip Flash */
   FLASH7           : origin = 0x0A0000, length = 0x008000  /* on-chip Flash */
   FLASH8           : origin = 0x0A8000, length = 0x008000  /* on-chip Flash */
   FLASH9           : origin = 0x0B0000, length = 0x008000  /* on-chip Flash */
   FLASH10          : origin = 0x0B8000, length = 0x002000  /* on-chip Flash */
   FLASH11          : origin = 0x0BA000, length = 0x002000  /* on-chip Flash */
   FLASH12          : origin = 0x0BC000, length = 0x002000  /* on-chip Flash */
   FLASH13          : origin = 0x0BE000, length = 0x001FF0  /* on-chip Flash */
//   FLASH13_RSVD     : origin = 0x0BFFF0, length = 0x000010  /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

   CPU1TOCPU2RAM   : origin = 0x03A000, length = 0x000800
   CPU2TOCPU1RAM   : origin = 0x03B000, length = 0x000800

 // CPUTOCMRAM      : origin = 0x039000, length = 0x000800

   CPUTOCMRAM_0     : origin = 0x039000, length = 0x000400
   CPUTOCMRAM_1     : origin = 0x039400, length = 0x000400
   CMTOCPURAM       : origin = 0x038000, length = 0x000800

   CANA_MSG_RAM     : origin = 0x049000, length = 0x000800
   CANB_MSG_RAM     : origin = 0x04B000, length = 0x000800

   RESET            : origin = 0x3FFFC0, length = 0x000002
}

SECTIONS
{
   codestart           : >BEGIN, ALIGN(8)
   .text               : >> FLASH1 | FLASH2 | FLASH3 | FLASH4, ALIGN(8)
   .cinit              : > FLASH1, ALIGN(8)
   .switch             : > FLASH2, ALIGN(8)
   .reset              : > RESET, TYPE = DSECT /* not used, */
   .stack              : > RAMM1

#if defined(__TI_EABI__)
   .init_array      : > FLASH3, ALIGN(8)
   .bss             : > RAMLS5
   .bss:output      : > RAMLS3
   .bss:cio         : > RAMLS5
   .data            : > RAMLS5
   .sysmem          : > RAMLS5
   /* Initalized sections go in Flash */
   .const           : > FLASH2, ALIGN(8)
#else
   .pinit           : > FLASH4, ALIGN(8)
   .ebss            : > RAMLS5
   .esysmem         : > RAMLS5
   .cio             : > RAMLS5
   /* Initalized sections go in Flash */
   .econst          : >> FLASH3 | FLASH4, ALIGN(8)
#endif

   ramgs0 : > RAMGS0, type=NOINIT
   ramgs1 : > RAMGS1, type=NOINIT
   
   MSGRAM_CPU1_TO_CPU2 : > CPU1TOCPU2RAM, type=NOINIT
   MSGRAM_CPU2_TO_CPU1 : > CPU2TOCPU1RAM, type=NOINIT

   MSGRAM_CPU_TO_CM  : > CPUTOCMRAM_0, type=NOINIT
   MSGRAM_CPU_TO_CM_COPY_TO_S0_RAM : > CPUTOCMRAM_1, type=NOINIT
   MSGRAM_CM_TO_CPU    : > CMTOCPURAM, type=NOINIT

   /* The following section definition are for SDFM examples */

   Filter1_RegsFile : > RAMGS10,	 fill=0x1111
   Filter2_RegsFile : > RAMGS11,	 fill=0x2222
   Filter3_RegsFile : > RAMGS12,	 fill=0x3333
   Filter4_RegsFile : > RAMGS13,     fill=0x4444
   Difference_RegsFile : >RAMGS14, 	 fill=0x3333


/*   Filter_RegsFile  : > RAMGS0
   Filter1_RegsFile : > RAMGS1, fill=0x1111
   Filter2_RegsFile : > RAMGS2, fill=0x2222
   Filter3_RegsFile : > RAMGS3, fill=0x3333
   Filter4_RegsFile : > RAMGS4, fill=0x4444
   Difference_RegsFile : >RAMGS5, fill=0x3333
   */

    GROUP
   {
	   .TI.ramfunc
	   { -l F2838x_C28x_FlashAPI_COFF_18.12.0.LTS.lib}

   } LOAD = FLASH1 | FLASH2 | FLASH3 | FLASH4,
     RUN =  RAMGS5 | RAMGS6 | RAMGS7 |RAMGS8,
	 LOAD_START(_RamfuncsLoadStart),
	 LOAD_SIZE(_RamfuncsLoadSize),
	 LOAD_END(_RamfuncsLoadEnd),
	 RUN_START(_RamfuncsRunStart),
	 RUN_SIZE(_RamfuncsRunSize),
	 RUN_END(_RamfuncsRunEnd),
	 ALIGN(8)

}

Anu,

Thanks for the linker cmd. But i am getting error 

"../2838x_FLASH_lnk_.cmd", line 128: error #10008-D: cannot find file "F2838x_C28x_FlashAPI_COFF_18.12.0.LTS.lib"
error #10010: errors encountered during linking; "F2838x_sci_flash_kernels_c28x_cm_cpu1.out" not built

But i can see the coff  Flash API library file in project . 

Thanks and Regards,

Stevin
 

Stevin, 

In the project settings, Go to C2000 Linker > File Search Path and add ${workspace_loc:/${ProjName}} under "Add <dir> to library search path". This should take care of that error. 

Thanks, 

Anu

HY Anu,

I'm still getting stuck at the same while loop. I have connected and run the cm . The IPC sync is not happening between copy functions. Is there any other change you have done  in project or code while you tried to load cm?

How did you build the CM kernel 8 bit stream ?, is the binary text file is causing the issue. Can u share the CM kernel txt file 

Thanks and Regards,

Stevin

Stevin, 

I did not make any other changes when getting the CM kernel to load. Are you following the steps in the readme when connecting to CPU1 and CM? You need to connect to CPU1 first and then CM.

If you click pause for CM, what address is showing up? When CM is waiting on CPU1 to set the boot mode, it should be in the address range 0x180C - 0x1818. You can refer to table 5-30 in the F2838x TRM to see the boot sections CM can wait in. When CPU1 is in the copy function, CM should be in S0RAM, somewhere in the 0x20000800 range. 

To format the txt file in the format needed for the kernels, you can use this post build step: 

"${CG_TOOL_HEX}" "${BuildArtifactFileName}" -boot -gpio8 -a -o "${BuildArtifactFileBaseName}.txt"

The CM kernel txt file was created with this command. 

Thanks, 

Anu

Hy Anu,

i am attaching ss where one is before booting cm other is after booting cm. As you can see PC is not pointing to S0RAM after boot also.

This is after DFU1 , i.e before CM boot

This one is after CM boot performed

There is no symbols under CM

Thanks and Regards,

Stevin

Stevin, 

Thanks for posting the screenshot. The address that CM is at after DFU1 tells me that CM is not waiting at the correct section in the boot code. Please follow the steps listed in the readme for connecting to CPU1 and CM. Specifically, these are the steps you need to follow: 

1. Connect to CPU1

2. Connect to CM

3. Click "Reset" for CPU1 - CM will be set to wait boot

4. Click "Resume" for CM - it should be waiting in the correct location

5. Load the kernel into CPU1 and click "Resume"

At this point you can use the serial flash programmer and be able to download the CM kernel. 

Thanks, 

Anu

Hy Anu, 

I will try and let you know. But when we are not using ccs , on running cpu1 kernel  in flash boot should keep copyfn()  in soRam of CM right?.Why is that not happening!

Thanks and Regards,

Stevin

Hy Anu,

I tried with readme file instructions , for one time it worked and downloaded CM kernel perfectly but after that previous stuck issue again came back. 

Again the confusion which still remains is that if we boot without using ccs the CM should be in wait boot and copy fn  in cpu1 and cm should be synchronizing. why is that not happening..

which boot pin mode are you using flash or SCI boot

Regards,

Stevin

Stevin, 

When using CCS with the CM kernel, in order to avoid getting stuck, you need to make sure that CM is waiting in the correct wait boot loop before CPU1 sets the boot mode for CM. 

When not using CCS, I used SCI Boot for the boot pin mode with serial_flash_programmer_f2838x_cm.exe and the CPU1 and CM copy functions were able to synchronize correctly. I will look into the Flash Boot issue, please give me a couple days to get back to you. In the meantime can you try with SCI Boot? Note that the CPU1 RAM build configuration needs to be used for SCI Boot. 

Thanks, 

Anu

Anu,

Thank you for all the support!!!!.SCI boot is working fine, with no issue.I will go own with SCI boot for now and please let me know when the issue is fixed. for flash SCI boot loader.

In SCI boot mode( Wait boot)  the boot ROM wait for a key , it jumps to flash only if the key is wrong. If one needs to use sci boot does thst mean upon every reset we need to provide a wrong key in order to boot into flash.  Is a soln available for that?

lastly, Is it possible to use etherCAT as the peripheral for boot loading  as i see etherCAT is connected to all 3 core , is it possible to update application using it?

Thanks and Regards,

Stevin

Stevin, 

For information on how to switch boot modes, please refer to the Boot chapter of the F2838x TRM. 

There is no EtherCAT bootloader available, you could create a custom bootloader and program it into Flash or RAM and use that to perform application updates. 

Thanks, 

Anu

Anu,

i have the project file of serial flash programmer , in that for run_cpu1_boot_cpu2 case ( which i have stored in flash  thus no loading required)  is commenting kernel download is required to stop kernel download and go with direct DFU2. Though Kernel download is commented out its not happening . Please guide through the changes i should make 

my aim is: As i have stored CPU2 kernel in Flash of CPU2 i need to stop kernel download for CPU2 when RUN_CPU1_BOOT_CPU2 option is given.

Thanks and Regards,

Stev

Stevin, 

The function call for the CPU2 kernel download should be commented out in the serial_flash_programmer file as well as in the CCS project for CPU1. The function SCI_Load_CPU2 looks for the kernel from the host to write to RAM. Commenting this out will skip this step on the target side. 

Thanks, 

Anu 

Hy Anu,

I have done this already , when the step mentioned above is done the download of kernel is skipped but DFU2 is getting stuck and not downloaded . 

regards,

Stev

Stevin, 

Maybe we can have a meeting to discuss further. Please contact your FAE and we can set up a meeting. 

Thanks,

Anu

Anu,

looking forward for replay from you regarding the issues we discussed during the meeting

Regards,

Stevin

Stevin, 

There are a few different options:

1. The first time you program the board, you can set the boot pins to SCI Boot and use the SCI Flash Kernel in RAM to write the application and kernel into Flash. The application can sit in the first few sectors of Flash and the next few sectors can be dedicated to the Flash kernel. After this, you can set the boot pins to Flash Boot and leave them as is and the application can signal the kernel when it wants the firmware upgraded. Given the discussions it seems like this is not what you are going for, but for the sake of completeness I am mentioning it here.
2. You can set the boot pins to SCI Boot and leave them as is. You can configure the User OTP to add two boot modes to the boot table – SCI Boot and Flash Boot. This would also require configuring a GPIO as a boot mode select pin to toggle between the boot modes – you would need to have access to the device when it’s in the field so that you can toggle the pin. For information on how to set up the boot table, you can refer to section 5.4 of the TRM. This seems like the ideal route to try out. 
3. If you have a GPIO pin to set up as a boot mode select pin, but don’t have access to toggle the pin in the field, you can refer to the app note SPRACN1 for a method on how to toggle the pin – if the boards are already produced this may not be viable but at a high level the application would have a way of driving the GPIO pin high when a firmware upgrade is needed. Here is the link to the app note: https://www.ti.com/lit/an/spracn1/spracn1.pdf
4. I checked with the boot owner and you can use USB Boot which will fallback to Flash Boot if the timeout occurs.

Thanks, 

Anu

Anu,

is USB boot loader available for f2838x ?

regards,

Stevin

Stevin, 

There is not a USB boot loader currently available. You can modify the SCI kernels to be used over USB. The F2837xD USB kernels could be used as a reference. 

Is the second option mentioned above not viable?

Thanks, 

Anu

Anu,

It seems ok, but i will check with my team and get back to you.

Thanks and regards,

Stevin

Stevin, 

Sure, sounds good. 

Thanks, 

Anu