This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F2810 CSM Locking Problem

Hello,

I'm having problems getting a program to run while my DSP is locked. I'm fairly new to DSPs and TI devices so forgive me if I'm asking something stupid.

I've got a program that I need to protect so I want to be able to lock the DSP using the CSM with a password. However, once I've programmed a password and locked the DSP, the program no longer runs after the device has been power cycled. As far as I can tell, everything is running from secure memory, but the program will only function when the device is unlocked.

I've started from some TI example linker files and have reallocated some blocks when I ran out of memory.

In order to run my program while the device is locked, do I need to run the whole program from flash memory? Any pointers would be greatly appreciated.

Many thanks

 

P.S. Linker code below:

 

MEMORY

{

PAGE 0:    /* Program Memory */

           /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE1 for data allocation */

 

   ZONE0       : origin = 0x002000, length = 0x002000     /* XINTF zone 0 */

   ZONE1       : origin = 0x004000, length = 0x002000     /* XINTF zone 1 */

   RAML0       : origin = 0x008000, length = 0x001000     /* on-chip RAM block L0 */

   ZONE2       : origin = 0x080000, length = 0x080000     /* XINTF zone 2 */

   ZONE6       : origin = 0x100000, length = 0x080000     /* XINTF zone 6 */

   OTP         : origin = 0x3D7800, length = 0x000800     /* on-chip OTP */

   FLASHE      : origin = 0x3E8000, length = 0x004000     /* on-chip FLASH */

   FLASHD      : origin = 0x3EC000, length = 0x004000     /* on-chip FLASH */

   FLASHC      : origin = 0x3F0000, length = 0x004000     /* on-chip FLASH */

   FLASHA      : origin = 0x3F6000, length = 0x001F80     /* on-chip FLASH */

   CSM_RSVD    : origin = 0x3F7F80, length = 0x000076     /* Part of FLASHA.  Program with all 0x0000 when CSM is in use. */

   BEGIN       : origin = 0x3F7FF6, length = 0x000002     /* Part of FLASHA.  Used for "boot to Flash" bootloader mode. */

   CSM_PWL     : origin = 0x3F7FF8, length = 0x000008     /* Part of FLASHA.  CSM password locations in FLASHA */

 

/* ZONE7       : origin = 0x3FC000, length = 0x003FC0     /* XINTF zone 7 available if MP/MCn=1 */ 

   ROM         : origin = 0x3FF000, length = 0x000FC0     /* Boot ROM available if MP/MCn=0 */

   RESET       : origin = 0x3FFFC0, length = 0x000002     /* part of boot ROM (MP/MCn=0) or XINTF zone 7 (MP/MCn=1) */

   VECTORS     : origin = 0x3FFFC2, length = 0x00003E     /* part of boot ROM (MP/MCn=0) or XINTF zone 7 (MP/MCn=1) */

 

PAGE 1 :   /* Data Memory */

           /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE0 for program allocation */

           /* Registers remain on PAGE1                                                  */

 

   RAMM0       : origin = 0x000000, length = 0x000400     /* on-chip RAM block M0 */

   RAMM1       : origin = 0x000400, length = 0x000400     /* on-chip RAM block M1 */

   RAML1       : origin = 0x009000, length = 0x001000     /* on-chip RAM block L1 */

   FLASHB      : origin = 0x3F4000, length = 0x002000     /* on-chip FLASH */

   RAMH0       : origin = 0x3F8000, length = 0x002000     /* on-chip RAM block H0 */

}

 

/* Allocate sections to memory blocks.

   Note:

         codestart user defined section in DSP28_CodeStartBranch.asm used to redirect code 

                   execution when booting to flash

         ramfuncs  user defined section to store functions that will be copied from Flash into RAM

*/ 

 

SECTIONS

{

 

   /* Allocate program areas: */

   .cinit              : > FLASHE      PAGE = 0

   .pinit              : > FLASHA,     PAGE = 0

   .text               : > FLASHE      PAGE = 0

   codestart           : > BEGIN       PAGE = 0

   ramfuncs            : LOAD = FLASHD, 

                         RUN = RAML0, 

                         LOAD_START(_RamfuncsLoadStart),

                         LOAD_END(_RamfuncsLoadEnd),

                         RUN_START(_RamfuncsRunStart),

                         PAGE = 0

 

   csmpasswds          : > CSM_PWL     PAGE = 0

   csm_rsvd            : > CSM_RSVD    PAGE = 0

 

   /* Allocate uninitalized data sections: */

   .stack              : > RAML1       PAGE = 1

   .ebss               : > RAML1       PAGE = 1

   .esysmem            : > RAML1       PAGE = 1

 

   /* For SDFlash to program these, they must be allocated to page 0 */

   .econst             : > FLASHD      PAGE = 0

   .switch             : > FLASHA      PAGE = 0    

 

   /* Allocate IQ math areas: */

   IQmath              : > FLASHC      PAGE = 0                  /* Math Code */

   IQmathTables        : > ROM         PAGE = 0, TYPE = NOLOAD   /* Math Tables In ROM */

 

   /* .reset is a standard section used by the compiler.  It contains the */ 

   /* the address of the start of _c_int00 for C Code.   /*

   /* When using the boot ROM this section and the CPU vector */

   /* table is not needed.  Thus the default type is set here to  */

   /* DSECT  */ 

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

   vectors             : > VECTORS     PAGE = 0, TYPE = DSECT

 

}

 

 

  • WillT said:
    I've got a program that I need to protect so I want to be able to lock the DSP using the CSM with a password. However, once I've programmed a password and locked the DSP, the program no longer runs after the device has been power cycled. As far as I can tell, everything is running from secure memory, but the program will only function when the device is unlocked.

    Can you provide more information.  How does the program behave?  (or misbehave)?

    What are the symptoms?

    What debug steps have you tried and what was the outcome?

    WillT said:
    In order to run my program while the device is locked, do I need to run the whole program from flash memory? Any pointers would be greatly appreciated.

    No, some code or data can be in RAM.  The basic rules are

    "secure can see all".  So if you have code running from secure memory (RAM or flash) it can access any data that is in secure or unsecure memory.

    "unsecure cannot see secure".  So if you have code running from unsecure memory, it could not read data that is in secure memory. 

    -Lori

  • Hi,

    I'm working on a motor controller. When the DSP is unlocked everything seems to work fine, but once it is locked it doesn't seem to do anything at all. It no longer sends or receives CAN messages (without which it wouldn't enable the PWM channels). Even the GPIO pins no longer seem to do what I would expect - I've got a 3-line position sensor going in which should toggle an output pin every time the input changes but doesn't work when locked.

    I'm not quite sure what to try to debug this as I can't seem to control any outputs.

    Any suggestions?

    Many thanks

  • Another suggestion is to build with the -w linker switch.  This will tell you if the linker is assigning any sections to memory that you did not specify in the linker command file.  I also suggest taking a look at the .map file to see if anything is executing in unsecure memory and may be trying to access secure memory.

    -Lori

  • Hi,

    I've tried the -w switch but I don't get any warnings. I don't think anything is wrong in the .map file either. One thing I've just thought of is that the DSP is on some hardware which by default runs a CAN bootloader on an external EEPROM. If this doesn't detect a download request after 0.5s it switches over to the DSP internal memory. Could locking the DSP stop the external bootloader from functioning?

    Also, if I disable the external bootloader by pulling the SCIRXDA pin high, my program won't run properly locked or unlocked. I can see through the JTAG that it is sampling the ADC and running various processes but I'm still not getting any CAN or GPIO working

    Thanks

    Will

  • WillT said:
    One thing I've just thought of is that the DSP is on some hardware which by default runs a CAN bootloader on an external EEPROM. If this doesn't detect a download request after 0.5s it switches over to the DSP internal memory. Could locking the DSP stop the external bootloader from functioning?

    Loaders would follow the same rules. 

    A couple of examples:

    The boot ROM of the device is in unsecure memory.  Therefore any loader running from the boot ROM would not be able to load into secure memory if the CSM were locked.  This loader would only be able to load into unsecure memory when the CSM is locked.

    The Flash is in secure memory.  Therefore if a loader is running from flash it will be able to load into secure memory if the CSM were locked.  It would also be able to load into unsecure memory.

    Regards

    -Lori

  • Thanks for the explanation. So if the boot ROM on the DSP is unsecured, how can I get it to run the program from the secured Flash? As I understand it the boot ROM checks the GPIO to decide where to boot to and in my case this is set to run from the 0x3F7FF6 location in FlashA.

    Many thanks

  • WillT said:
    So if the boot ROM on the DSP is unsecured, how can I get it to run the program from the secured Flash? As I understand it the boot ROM checks the GPIO to decide where to boot to and in my case this is set to run from the 0x3F7FF6 location in FlashA.

    The security won't prevent code execution from transferring from unsecure to secure (ex boot ROM branch to flash).  It will only prevent unsecure code from reading/writing to secure memory.

    So while the code is executing in the boot ROM it will not be able to read/write to unsecure memory. 

    Once execution has transferred to secure memory (via the boot ROM branch to flash) then the code will be able to read/write to secure memory.

    cheers

    -Lori

  • Great, so there's no reason why it shouldn't start up ok.

    I've been doing some debugging running the program with the boot ROM set to load straight to flash. With the JTAG I can see that all parts of my program are definitely running - all the program variables are changing as they should be, but for some reason I am still not getting any messages being sent or received over CAN or control over the GPIO.

    Can you think of any reason why it would make a difference booting straight to flash rather than to flash via an external bootloader (after which everything works fine), and why this would have any effect on the CAN module?

    Many thanks

    Will 

  • Great, so there's no reason why it shouldn't start up ok.

    I've been doing some debugging running the program with the boot ROM set to load straight to flash. With the JTAG I can see that all parts of my program are definitely running - all the program variables are changing as they should be, but for some reason I am still not getting any messages being sent or received over CAN or control over the GPIO.

    Can you think of any reason why it would make a difference booting straight to flash rather than to flash via an external bootloader (after which everything works fine), and why this would have any effect on the CAN module?

    Many thanks

    Will