TMS320F28386S: Placing flash kernels in flash

Part Number: TMS320F28386S

Because our hardware was not designed with the correct pin pairs for SCIA boot firmware updating with the serial flash programmer we must have a modified design.

I experimented with building the CPU1 kernel as a RAM project and ran it, and this seemed to work OK. However, I did not look far enough ahead. It is much more complicated to use the serial flash programmer to update the CM. There is a 2nd kernel which must be loaded in CPU1 and another one for the CM. After the CPU1 kernel loads the CM kernel then the original CPU kernel must be reloaded to update the CM app. In threads and conversations with a TI E2E engineer it seems it would help if I put the kernels in flash in a location that would not be affected by updates. The location would be controlled by the linker cmd file. So 3 questions arise.

1) Should these kernels (2 for CPU1 and 1 in the CM) run from flash or should they be RAM based as they originally operate and copied into RAM to run? I think operating from flash is OK if the kernel's region specified by the linker cmd file is not erased or overwritten.

2) This forum may not be the right place for this question but I would appreciate some redirection if I should look elsewhere. Would these kernels be called as functions from my regular main app or would a branch be used?

3) Again maybe the wrong forum. How would these functions or images be isolated in the linker cmd file?

Thanks,

John

Hi John,

1) Parts of the kernel can be made to run from Flash, but other processes like the stack are required to run from RAM. 

2) For your usage the kernels should be called by a branch. Do you anticipate the application running and then calling the kernels as functions?

3) Both CPU1 and CM kernels can be run from from flash by using the 2838x_FLASH_lnk_cpu1.cmd or 2838x_FLASH_lnk_shared_cm.cmd found in C2000Ware_4_02_00_00\device_support\f2838x\common\cmd. The functions are naturally isolated as they use different flash banks. 

Thanks,

Charles

Hi Charles and thanks for the quick response.

1) Yes, of course. I should have specified the stack and variables.

2) I assumed I would need to call them as functions. I do not know another way as the goal is to be able to upgrade the app without using JTAG.But any ideas are welcome.

3) Thanks for this. I will study it, which means more questions later but I wanted to respond to 1 and 2 as quickly.

John

Hi John,

On 2) You can call them as a function, doing so it will send you to the SCI bootloader to download the kernel via SCI. As long as it is not connected to your JTAG default pins (for your situation).

Thanks,

Charles

2) That would not be good at all. Our SCIA pin configuration is the root of all of this problem.If the SCI bootloader starts I am locked out as it uses pins pairs we do not have.

I see, right. You can modify the sciGetFunction so that you won't have to rely on that pin 28/29 pin pair combination. 

A) There is a problem using 2838x_FLASH_lnk_cpu1.cmd and there may be a similar problem with the CM. This link file puts the kernel is the same place as my original app. I need for both of them to be in flash at the same time so my app can call the kernel. So I need to know how to specify an address for a specific piece of flash code. Since the app is about to be overwritten in lower flash this code could be called via a jump or branch.

B) Also the kernel will need space for initialized variables, etc. So .text, .cinit, and .switch? From what I understand this could be contiguous with the app initialized variable space. Hopefully uninitialized variables can share space.

C) Looking at my app map file it seems there is plenty of empty flash space.

D) When a firmware update is performed I need to find a way to do it so that kernel in flash is not part of the update. This leads me to conclude that it may be better for the kernel to be copied from flash and executed in RAM.

JH

Hi John,

Thanks for the questions. 

A) Understood, so both the kernel and your application will reside in flash. In order to specify an address for the kernel, it needs to just not overlap with the application file's address.

B/C) Initialized variables for .text, .cinit, and .switch can be stored in flash if needed. 

For D, I do think it would be better for the kernel to be copied from flash and executed in RAM.

Charles

D) Good. I am largely ignorant of the process. Is there some TI material available.

John, I would reference the flashapi_ex1_programming project and the assembly language tools guide (https://www.ti.com/lit/ug/sprui03e/sprui03e.pdf) for the linker command file. 

I'll have to continue looking into this a bit later today.

Thanks,

Charles

Thanks for the tip.

I built a cmd file but I don't know what ram section to use, LS or GS. Is there a general preference.

The cmd file:

MEMORY
{

   /* BEGIN is used for the "boot to SARAM" bootloader mode   */
   //BEGIN            : origin = 0x000000, 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" */

   /* BEGIN is used for the "boot to Flash" bootloader mode   */
   BEGIN            : origin = 0x080000, length = 0x000002
   /* 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 */
/*
#ifdef __TI_COMPILER_VERSION__
  #if __TI_COMPILER_VERSION__ >= 20012000
}  crc(_table_name, algorithm=C28_CHECKSUM_16)
  #endif
#endif
*/
   CPU1TOCPU2RAM_0  : origin = 0x03A000, length = 0x000400
   CPU1TOCPU2RAM_1  : origin = 0x03A400, length = 0x000400
   CPU2TOCPU1RAM    : origin = 0x03B000, length = 0x000800

   CPUTOCMRAM       : origin = 0x039000, length = 0x000800
   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

   kernel_section : 
   {
		flash_kernel_c28x_dual_ex1_boot_cpu1.obj(.text)
		flash_kernel_c28x_dual_ex1_erase_cpu1.obj(.text)
		flash_kernel_c28x_dual_ex1_sci_boot_cpu1.obj(.text)
		flash_kernel_c28x_dual_ex1_sci_flash_kernel_cpu1.obj(.text)
		flash_kernel_c28x_dual_ex1_sci_get_function_cpu1.obj(.text)
		flash_kernel_c28x_dual_ex1_verify_cpu1.obj(.text)

   }    LOAD >> FLASH5, // | FLASH6 | FLASH7 | FLASH8 | FLASH9 | FLASH11 | FLASH12,
        RUN >> RAMLS0 | RAMLS1 | RAMLS2 |RAMLS3,
        LOAD_START(RamfuncsLoadStart),
        LOAD_SIZE(RamfuncsLoadSize),
        LOAD_END(RamfuncsLoadEnd),
        RUN_START(RamfuncsRunStart),
        RUN_SIZE(RamfuncsRunSize),
        RUN_END(RamfuncsRunEnd),
        ALIGN(4)

   .text            : >>RAMGS1 | RAMGS2 | RAMGS3 | RAMGS4
   .cinit           : > RAMM0
   .switch          : > RAMM0
   .reset           : > RESET,    TYPE = DSECT /* not used, */

   .stack           : > RAMM1
#if defined(__TI_EABI__)
   .bss            : > RAMGS5
   .data           : > RAMGS5
   .const          : > RAMGS5
   .init_arry      : > RAMM0
   .sysmem         : > RAMGS5
#else
   .pinit           : > RAMM0
   .ebss            : > RAMGS5
   .econst          : > RAMGS5
   .esysmem         : > RAMGS5
#endif

   Filter_RegsFile  : > RAMGS5

#ifdef __TI_COMPILER_VERSION__
    #if __TI_COMPILER_VERSION__ >= 15009000
       .TI.ramfunc      : > RAMGS5
    #else
       ramfuncs         : > RAMGS5
    #endif
#endif

   MSGRAM_CPU1_TO_CPU2 > CPU1TOCPU2RAM_0, type=NOINIT
   MSGRAM_CPU1_TO_CPU2_COPY_TO_M1_RAM > CPU1TOCPU2RAM_1, type=NOINIT
   MSGRAM_CPU2_TO_CPU1 > CPU2TOCPU1RAM, type=NOINIT
   MSGRAM_CPU_TO_CM   > CPUTOCMRAM, 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

}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

Thanks,

John

Hi John,

Either LS or GS would be fine to use, but I would lean towards GS since you have more sectors available. LS RAM is shared between C28x CPU and CLA, GS RAM shared between CPU, CPU2, DMA accesses. 

Thanks,

Charles