TMS320F280049C: CPU read secured CLA data through CLA-to-CPU MSGRAM

Julia Li

Expert 3800 points

Part Number: TMS320F280049C

Hi Champs,

I ask this for our customer.

1. Since LS RAM can be encrypted, CLA-to-CPU can not. Is this understanding correct?

The encrypted area can access CPU-to-CLA RAM, that is, the encrypted CLA area can get the data transmitted from the CPU

But the CPU cannot obtain the encrypted data in the CLA through CLA-to-CPU RAM

2. Customer now have a problem that when they are not using DCSM, the code runs fine, but after using DCSM, when the code is run without decryption, the encrypted CLA fails to access the data of CPU-TO-CLA (data by DAC output, output is 0).

I checked the configuration of the customer's .cmd file and there should be no errors that unencrypted RAM to access encrypted RAM. Couls you help analyze the reason? Thanks!

Fullscreen

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
MEMORY
{
PAGE 0 :
   /* BEGIN is used for the "boot to Flash" bootloader mode   */
      /* not boot used*/
   BEGIN           : origin = 0x080000, length = 0x000002
   CLA_PROG_RAM     : origin = 0x008000, length = 0x003800
   RESET             : origin = 0x3FFFC0, length = 0x000002
   RAMGS1           : origin = 0x00E000, length = 0x002000
   RAMGS2           : origin = 0x010000, length = 0x002000
   /* Flash sectors */
   /* BANK 0 */
   HEADERINFO       : origin = 0x084000, length = 0x000100, fill 0xFFFF /* on-chip Flash */
   CPU_PROG_FLASH      : origin = 0x084102, length = 0x00BEFE/* on-chip Flash */
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

MEMORY
{
PAGE 0 :
   /* BEGIN is used for the "boot to Flash" bootloader mode   */

      /* not boot used*/
   BEGIN           : origin = 0x080000, length = 0x000002
   CLA_PROG_RAM     : origin = 0x008000, length = 0x003800

   RESET             : origin = 0x3FFFC0, length = 0x000002


   RAMGS1           : origin = 0x00E000, length = 0x002000
   RAMGS2           : origin = 0x010000, length = 0x002000

   /* Flash sectors */
   /* BANK 0 */
   HEADERINFO       : origin = 0x084000, length = 0x000100, fill 0xFFFF /* on-chip Flash */
   CPU_PROG_FLASH      : origin = 0x084102, length = 0x00BEFE/* on-chip Flash */


   /* BANK 1 */
   CLA_PROG_FLASH    : origin = 0x090000, length = 0x004000    /* on-chip Flash */
   FLASH_BANK1_SEC4  : origin = 0x094000, length = 0x001000    /* on-chip Flash */
   FLASH_BANK1_SEC5  : origin = 0x095000, length = 0x001000    /* on-chip Flash */
   FLASH_BANK1_SEC6  : origin = 0x096000, length = 0x001000    /* on-chip Flash */
   FLASH_BANK1_SEC7  : origin = 0x097000, length = 0x001000    /* on-chip Flash */
   FLASH_BANK1_SEC8  : origin = 0x098000, length = 0x001000    /* on-chip Flash */
   FLASH_BANK1_SEC9  : origin = 0x099000, length = 0x001000    /* on-chip Flash */
   FLASH_BANK1_SEC10 : origin = 0x09A000, length = 0x001000    /* on-chip Flash */
   FLASH_BANK1_SEC11 : origin = 0x09B000, length = 0x001000    /* on-chip Flash */
   FLASH_BANK1_SEC12 : origin = 0x09C000, length = 0x001000    /* on-chip Flash */
   FLASH_BANK1_SEC13 : origin = 0x09D000, length = 0x001000    /* on-chip Flash */
   FLASH_BANK1_SEC14 : origin = 0x09E000, length = 0x001000    /* on-chip Flash */
   FLASH_BANK1_SEC15 : origin = 0x09F000, length = 0x001000    /* on-chip Flash */

PAGE 1 :

   BOOT_RSVD        : origin = 0x000002, length = 0x0000F3     /* Part of M0, BOOT rom will use this for stack */
   RAMM1            : origin = 0x000400, length = 0x000400     /* on-chip RAM block M1 */

   RAMLS7             : origin = 0x00B800, length = 0x0007F8

   RAM_STACK        : origin = 0x00C000, length = 0x000C00
   RAMGS0           : origin = 0x00CC00, length = 0x001400
   RAMGS3           : origin = 0x012000, length = 0x002000

   CLA1_MSGRAMLOW   : origin = 0x001480, length = 0x000080
   CLA1_MSGRAMHIGH  : origin = 0x001500, length = 0x000080
}


SECTIONS
{
   codestart        : > BEGIN,              PAGE = 0, ALIGN(4)
   .text            : >>CPU_PROG_FLASH,     PAGE = 0, ALIGN(4)
   .cinit           : > CPU_PROG_FLASH,     PAGE = 0, ALIGN(4)
   .pinit           : > CPU_PROG_FLASH,     PAGE = 0, ALIGN(4)
   .switch          : > CPU_PROG_FLASH,     PAGE = 0, ALIGN(4)
   .reset           : > RESET,              PAGE = 0, TYPE = DSECT /* not used, */

   .cio             : > RAMGS1,    PAGE = 0
   .stack           : > RAM_STACK,    PAGE = 1
   .ebss            : > RAMGS0,    PAGE = 1
   .esysmem         : > RAMGS3,    PAGE = 1
   .econst          : > CPU_PROG_FLASH,    PAGE = 0, ALIGN(4)

   ramgs0           : > RAMGS0,    PAGE = 1
   ramgs1           : > RAMGS3,    PAGE = 1
    
   .reset           : > RESET,     PAGE = 0, TYPE = DSECT /* not used, */
   
    /* CLA specific sections */
    Cla1Prog        : LOAD = CLA_PROG_FLASH,
                      RUN = CLA_PROG_RAM,
                      LOAD_START(_Cla1ProgLoadStart),
                      RUN_START(_Cla1ProgRunStart),
                      LOAD_SIZE(_Cla1ProgLoadSize),
                      PAGE = 0, ALIGN(4)
  
    
    Cla1ToCpuMsgRAM  : > CLA1_MSGRAMLOW,   PAGE = 1
    CpuToCla1MsgRAM  : > CLA1_MSGRAMHIGH,  PAGE = 1

    /*.TI.ramfunc      : LOAD = CPU_PROG_FLASH, */
    GROUP
    {
        .TI.ramfunc
        { -l F021_API_F28004x_FPU32.lib}

    } LOAD = CPU_PROG_FLASH,
      RUN = RAMGS1 | RAMGS2,
      LOAD_START(_RamfuncsLoadStart),
      LOAD_SIZE(_RamfuncsLoadSize),
      LOAD_END(_RamfuncsLoadEnd),
      RUN_START(_RamfuncsRunStart),
      RUN_SIZE(_RamfuncsRunSize),
      RUN_END(_RamfuncsRunEnd),
      PAGE = 0, ALIGN(4)


   .scratchpad      : > RAMLS7,           PAGE = 1
   .bss_cla         : > RAMLS7,           PAGE = 1

   Cla1DataRam      : > RAMLS7,           PAGE = 1

   .const_cla       :  LOAD = CLA_PROG_FLASH,
                       RUN = CLA_PROG_RAM,
                       RUN_START(_Cla1ConstRunStart),
                       LOAD_START(_Cla1ConstLoadStart),
                       LOAD_SIZE(_Cla1ConstLoadSize),
                       PAGE = 0
   CodeInfoFile    : > HEADERINFO,       PAGE = 0
}

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

Best Regards,

Julia

over 3 years ago

0 Julia Li over 3 years ago

TI__Expert 3800 points

Hi,

Can someone answer my question? Thanks!

Best Regards,

Julia

0 Pramod P over 3 years ago in reply to Julia Li

TI__Expert 5350 points

Hi Julia,

I was out of office for the past week. Apologies for the late response.

Julia Li said:
Since LS RAM can be encrypted, CLA-to-CPU can not. Is this understanding correct?

Your understanding is correct.

Julia Li said:
The encrypted area can access CPU-to-CLA RAM, that is, the encrypted CLA area can get the data transmitted from the CPU

But the CPU cannot obtain the encrypted data in the CLA through CLA-to-CPU RAM

I am answering below based on whatever I could gather from your question. Feel free to modify your question if you think I have not properly interpreted your question.

The Encrypted area (LS RAM) can be used by CLA to get data transmitted from the CPU-to-CLA RAM.

CLA-to-CPU RAM can only be written by CLA and not by CPU.

Julia Li said:
Customer now have a problem that when they are not using DCSM, the code runs fine, but after using DCSM, when the code is run without decryption, the encrypted CLA fails to access the data of CPU-TO-CLA (data by DAC output, output is 0).

I see you use the term encrypted CLA... Can you please tell me if you are referring to the CLA as a peripheral (if yes, then your understanding is incorrect.) LS RAMs are secure and CLA has access the these memories.

Also, what do you mean by when the code is run without decryption?

Please share the security settings that has been configured for the program for further analysis on this.

0 Julia Li over 3 years ago in reply to Pramod P

TI__Expert 3800 points

Hi Pramod,

"encrypted CLA" means allocate secured LS RAM to CLA, sorry I didn't express clearly. Now the problem is when customer not set the password, the code works well, but when customer set the password, CLA(is allocated secured LS RAM) cannot read the data from CPU-TO-CLA(unsecured), customer use DAC to output the data but the output is 0.

Due to customer's policy, I cannot disclose this part of security settings code, and I have sent the code to you offline.

The initialization of the DAC is configured in the CPU, and the variables representing the output value of the DAC will be accumulated in the CPU, then written to the CPU-TO-CLA MSGRAM, and then read by the CLA.

Best Regards,

Julia

0 Pramod P over 3 years ago in reply to Julia Li

TI__Expert 5350 points

This thread is being handled offline and will post a conclusion once the query is resolved.

Thanks & Regards

Pramod

0 Santosh Jha over 2 years ago in reply to Pramod P

TI__Guru 50470 points

Pramod,

This thread is about to be locked. Any update to close it?

0 Pramod P over 2 years ago in reply to Santosh Jha

TI__Expert 5350 points

Santosh,

I identified the root cause (copy of data from unsecure memory to secure memory which is not allowed when the Zone is secure). Yet to receive a word from the customer if the issue is resolved.

Thanks & Regards

Pramod

+1 Pramod P over 2 years ago in reply to Pramod P

TI__Expert 5350 points

The root cause has been identified. The memcpy function used in the application was actually resulting the data transfer from unsecure memory to secure memory which is not allowed when the zone is secure. This resulted in CLA not getting configured properly and hence application was not able to run. Once the memcpy routine was moved to the secure memory, the data transfer happened without any problems and the application was able to run.

Julia, please add any further details if necessary and kindly mark the thread as resolved if there are no further questions regarding this.

Thanks & Regards

Pramod

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F280049C: CPU read secured CLA data through CLA-to-CPU MSGRAM