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.

TMS320F28023: calculate flash checksum

Part Number: TMS320F28023


Dear Champs,

Our factory request the checksum should be send out via UART. So I implement a checksum calculation code as show below, the code works good if no pass word programmed into device. But it can not work after program password programmed. 

Uint16 flash_checksum_calculate(Uint16 *StartAddr,Uint16 size)

{

    volatile Uint16 checksum = 0;

    volatile Uint16 i = 0;

 

    for(i = 0; i < size; i++)

    {

        checksum += (Uint16)(*StartAddr++);

        checksum = checksum&0xFFFF;

    }

 

    return checksum;

}

 

Uint16 flash_checksum;

 

void main(void)

{

    init_system_and_device(); 

    //flash start address = 0x3F0000

    //flash size = 0x8000, 32KB

    flash_checksum = flash_checksum_calculate((Uint16 *)0x3F0000, (Uint16)0x8000);

    ... ... 

}

After go through system ref manual, use the C code example of secure and unsecure flash as show below, but it still can't work, and it looks to me that CPU are stuck in somewhere after using unsecure_flash and secure_flash. Can you please help me on that? What my expected is that the firmware should support to calculate flash checksum under both with and without password. Thanks...

   unsecure_flash();

    //flash start address = 0x3F0000

    //flash size = 0x8000, 32KB

    flash_checksum = flash_checksum_calculate((Uint16 *)0x3F0000, (Uint16)0x8000);

   secure_flash();

My unsecure code:

void unsecure_flash(void)
{
volatile int *CSM = (volatile int *)0x000AE0; //CSM register file
volatile int *PWL = (volatile int *)0x003F7FF8; //Password location
volatile int tmp[8];
int I = 0;
// Read the 128-bits of the password locations (PWL)
// in flash at address 0x3F 7FF8 - 0x3F 7FFF
// If the device is secure, then the values read will
// not actually be loaded into the temp variable, so
// this is called a dummy read.
for (I=0; I<8; I++) tmp[I] = *PWL++;

//if(secure_flag == 1)
//If the password is not all ones (0xFFFF), then the code below is required
// to unsecure the CSM.

// Write the 128-bit password to the KEY registers
// If this password matches that stored in the
// PWL then the CSM will become unsecure. If it does not
// match, then the device will remain secure.
// An example password of:
// 0x11112222333344445555666677778888 is used.
asm(" EALLOW"); // Key registers are EALLOW protected
*CSM++ = 0xFFFF; // Register KEY0 at 0xAE0
*CSM++ = 0xFFFF; // Register KEY1 at 0xAE1
*CSM++ = 0xFFFF; // Register KEY2 at 0xAE2
*CSM++ = 0xFFFF; // Register KEY3 at 0xAE3
*CSM++ = 0xEBEE; // Register KEY4 at 0xAE4
*CSM++ = 0xD8FF; // Register KEY5 at 0xAE5
*CSM++ = 0xE9D3; // Register KEY6 at 0xAE6
*CSM++ = 0xAB38; // Register KEY7 at 0xAE7
asm(" EDIS");
}

       

void resecure_flash(void)
{
volatile int *CSMSCR = (volatile int *)0x00AEF; //CSMSCR register
//Set FORCESEC bit
asm(" EALLOW"); //CSMSCR register is EALLOW protected.
*CSMSCR = 0x8000;
asm("EDIS");
}

  • Another question about this, if some of the initial values are stored in flash, if I'd like to copy it to ram variables, how to realize it if password are programmed?
  • On a secure device, code executing from unsecure memory cannot access contents of in secure memory when JTAG is connected. If you execute checksum algorithm also in secure memory then you shouldn't have problems.

    For copying some initial values from flash to RAM (non-secure memory), you need to unlock the device. If you are copying to flash contents to secure RAM memory, you don't need to unlock the device.

    Regards,
    Manoj
  • Dear Manoj,

    Here is address of the flash_checksum variable and flash_checksum_calculate function within my project, do you think both are within secure memory?
    00008d0c _flash_checksum
    003f3db5 _flash_checksum_calculate

    BTW, what is the address range of secured/unsecured memory?
  • Dear Manoj,

    Regarding to the comments from system reference manual, "The device is secure when CPU access to the on-chip secure memory locations is restricted. When secure, two levels of protection are possible, depending on where the program counter is currently pointing. If code is currently running from inside secure memory, only an access through JTAG is blocked (that is, through the emulator). This allows secure code to access secure data. Conversely, if code is running from nonsecure memory, all accesses to secure memories are blocked. User code can dynamically jump in and out of secure memory, thereby allowing secure function calls from nonsecure memory."

    I think the L0SRAM and Flash are secured memory. Below picture shows my flash_checksum algorithm runs in flash(PC are pointed to 0x3F3DB9 while executing this fucntion), but the local variable(checksum) are stored in M1SARAM, which is non-secure memory, what's the risks for local variable(checksum) to store the calculated checksum in secure mode? 

  • Jack,

    Entire flash, USER OTP and L0SRAM is secure. M0/M1 SRAM is unsecure memory. Please check Figure 6-1 in F28023 datasheet for more details.

    You shouldn't have any issues in storing calculated checksum in non-secure memory.

    Regards,
    Manoj
  • Dear Manoj,

    Below table from System Ref manual says, CPU has full access as long as program fetch inside secure memory.

    Is that means there is no limitation for CPU as long as the PC pointed to secure memory?

    And without unlocking device, there is no problem for copying data from flash to RAM(unsecure memory) if the copying function store and runs in flash, right? 

  • Dear Manoj,

    I found that why my project can't work, it relates to where does .stack and .ebss be allocated.

    If .stack allocated to L0SARAM, and password are programmed, then device won't work.
    .stack : > D_RAML0 PAGE = 1
    .ebss : > RAMM0_M1 PAGE = 1

    But if .stack is allocated to M0/M1, there is no problem with/without password programmed. Can you please let me know why?
    .stack : > RAMM0_M1 PAGE = 1
    .ebss : > RAMM0_M1 PAGE = 1

    MEMORY's Configuration:
    PAGE 1 : /* Data Memory */
    RAMM0_M1 : origin = 0x000000, length = 0x000800 /* on-chip RAM block M0 + M1 */
    D_RAML0 : origin = 0x008800, length = 0x0000800 /* on-chip DRAM block L0 */

    In addition, what criterion of allocating the section if password are programmed? .stack, .ebss, .text, .cinit, and etc.
  • Manoj,

    Can you please share your further comments here?
  • Jack,

    I'm glad you were able to get your code working.

    Stack can be in D_RAML0. So, not sure why you see this problem. One possible reason could be stack corruption.

    Regards,
    Manoj
  • Can I close this thread?

    -Manoj
  • Manoj,

    Thanks for your strong support. May I get your comments in below 2 question?

    1. Is that means there is no limitation for CPU as long as the PC pointed to secure memory?

    2. And without unlocking device, there is no problem for copying data from flash to RAM(unsecure memory) if the copying function store and runs in flash, right?
  • Jack,

    On a secure device, copying contents from flash to secure RAM will not be a problem. But, copying contents from flash to unsecure memory will be problem.

    On an unsecure device, copying contents from flash to secure (or) unsecure RAM will not be a problem.

    Regards,
    Manoj
  • It looks to me that the reference manual is conflict with what your comment.If code is running in flash, CPU has full access. Can you please help to double confirm this? 

    Ref manual Say, "The device is secure when CPU access to the on-chip secure memory locations is restricted. When
    secure, two levels of protection are possible, depending on where the program counter is currently
    pointing. If code is currently running from inside secure memory, only an access through JTAG is blocked
    (that is, through the emulator). This allows secure code to access secure data."

  • Jack,

    I'm not sure what is the conflict. Running code from secure memory provides full access to secure memory and it is not contradictory to my above statement.

    Regards,
    Manoj
  • Manoj,

    Regarding to your comments, "But, copying contents from flash to unsecured memory will be problem." , actually I have tested it on secured device, it looks to me there is no problem if copying function are stored and run in flash without unlock device.

    In my understanding, there is no limitation to access(include read and write) unsecured memory. But why does CPU can read secured flash, but can't write to unsecured RAM?

  • Jack,

    Okay. It looks like I got that wrong. You shouldn't have problem copying secure memory contents to unsecure memory. But, you will have problems when accessing secure memory contents from code executing from unsecure memory.

    Regards,
    Manoj
  • Manoj,

    Thanks for your strong support and confirm.