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.

TMS320F280049: FLASH CRC/DCSM

Part Number: TMS320F280049


hello, dear

i am doing the safety test for chip, and i got some questions about CRC/DCSM part.

1. for dcsm, i depart the program for secured and unsecured. calculateECC() in secured part, i did the crc calculation and got the crcObj.crcResult as the golden crc. i write it to the goldenCRC, and then program some  unsecured part(outside of FlashFusa2) . after reflash, the crc changed. why not fix to goldenCRC?

2.In the Safety Manual for TMS320F28004x. DCSM8 asks for VCU CRC Check of Static Memory Contents. Does that mean the goldenCRC for secured part and goldenCRC for unsecured part should Independence  not affect each other?  Or just ask for the same as last time?

   thanks

crcObj.seedValue = STL_CRC_INIT_CRC;
crcObj.numBytes =0xfff;
crcObj.parity = STL_CRC_PARITY_EVEN;
crcObj.crcResult = 0U;
crcObj.msgBuffer = (void *) 0x098000;

STL_CRC_calculate(&crcObj);

#pragma DATA_SECTION(xorData,"ramgs1");
uint64_t xorData;

#pragma CODE_SECTION(calculateECC,"FlashFusa2" );
void calculateECC(void);

 void calculateECC(void)
{

xorData = xorData ^ (xorData >> 32);

}

in cmd:

RAMGS1        : origin = 0x00E000, length = 0x002000

FLASH_FUSA2        : origin = 0x098000, length = 0x001000 /* on-chip Flash */

FlashFusa2       : > FLASH_FUSA2           PAGE = 0

 ramgs1           : > RAMGS1,    PAGE = 1

  • Hi Jane,

    i did the crc calculation and got the crcObj.crcResult as the golden crc. i write it to the goldenCRC, and then program some  unsecured part(outside of FlashFusa2) . after reflash, the crc changed. why not fix to goldenCRC?

    I am not very clear on this query. Are you programming secure and non-secure code separately, in two step process ? If yes, then please make sure there is no section getting over written. As long as content is same the CRC value should not change.

    Regards,

    Vivek Singh

  • yes. I programming secure and non-secure code separately, in two step process. and i found the flash will change 

    when execute  'xorData = xorData ^ temp1' .As the picture shows, i read the disassembly and found '00C955A5    FFC          XAR7, LL$$XOR '(high lightened in the picture) will change if i program the non-secure code. That changes the secure section flash value.

    I make sure there is no section getting over written.

    how to fix the LL$$XOR to a certain location in flash?

    #pragma DATA_SECTION(temp1,"ramgs1");
    #pragma DATA_SECTION(xorData,"ramgs1");
    uint64_t xorData,temp1;

    #pragma CODE_SECTION(calculateECC,"FlashFusa2" );
    void calculateECC(void);

    void calculateECC(void)
    {xorData = xorData ^ temp1;}

  • Hi,

    and i found the flash will change 

    when execute  'xorData = xorData ^ temp1' .

    Flash is non-volatile memory so it should not change by executing a simple instruction. 

    As the picture shows, i read the disassembly and found '00C955A5    FFC          XAR7, LL$$XOR '(high lightened in the picture) will change if i program the non-secure code.

    Ok, this is still confusing. Is the flash value changing after you load non-secure code or when you execute "xorData = xorData ^ temp1' " ?

    Sorry, I am still trying to understand the issue you are facing. 

    Vivek Singh

  • sorry. i should express more clearly.

    1.  I used a specific area as a security area (0x98000-----0x99000), and perform CRC check on this flash area (that is, compare it with goldenCRC, if it is consistent, it is ok).  As shown below: in the safe area only has calculateECC(), do xorData = xorData^temp1;.  the flash value is shown in figure1. 

    #pragma CODE_SECTION(calculateECC,"Flash_Bank1_Sec8" );
    void calculateECC(void);

    #pragma DATA_SECTION(temp1,"ramgs1");
    #pragma DATA_SECTION(xorData,"ramgs1");
    uint64_t xorData,temp1;

    void calculateECC(void)

    {xorData = xorData ^ temp1;}

                                           figure1

                                           figure 2

    2. then i add the mytest() function locate in another flash bank, as shown below. then debug, the flash of  (0x98000-----0x99000) changed.

    #pragma CODE_SECTION(mytest,"Flash_Bank1_Sec0" );
    void calculateECC(void);

    #pragma DATA_SECTION(temp2,"ramls5");
    uint64_t temp2;

    void mytest( void )
    {
    temp2=1;
    }

    3. I comare the disassembly and map shown as below.  and find when execute  FFC          XAR7, LL$$XOR. the LL$$XOR changed in flash. 

    my question is how to fix the function calculateECC() to a golden CRC?

    THANKS

  • #pragma CODE_SECTION(mytest,"Flash_Bank1_Sec0" );
    void mytest(void);

  • Hi Jane,

    You are compiling the code again with some changes done in the code. Compiler can re-assign function address in that case hence you may see a different value. There is nothing wrong in that. You should calculate the golden CRC on final compile code only. 

    I'll let someone from compiler team to provide there additional comment on this.

    Regards,

    Vivek Singh

  • Use the standalone disassembler dis2000 to inspect the program.  It is located in the same directory as the compiler cl2000.  From the command line, run a command similar to ...

    % dis2000 final_executable.out > final_executable_dis.txt

    Inspect final_executable_dis.txt.  I'm confident the encoding of the problem FFC instruction will be correct.  Then load (or flash) the program into the system.  Inspect the memory location for the problem FFC instruction.  Does it match what is in the disassembly file?  As the program executes, do the contents of the problem memory location ever change?

    Thanks and regards,

    -George

  • thanks for your help.

    i am not quite sure about how to oprate. i can fount the dis2000.exe file. 

    and running that file.

    is that step ok?

    but it still. Once i program mytest() or delete it. 

    void mytest( void )
    {
    temp2=1;
    }

    the LL$$XOR in map will change the location.

    the LL$$XOR in map match what is in the disassembly file.

    i want the LL$$XOR will fix to a location in map. then i can get a fixed CRC.

    thanks

  • Please consider a simple example program.  This example is not a real program.  

    Presume the entire program has three functions.  These functions are named one, two, and three.  They are located in memory in that order.  Presume the address of one is 0x100, the address of two is 0x180, and the address of three is 0x200.  Suppose you add some code to one that makes it 0x10 words bigger.  The address of one does not change.  It is still at 0x100.  But the address of two changes to 0x190, and the address of three changes to 0x210.  Is that clear?

    The way you perform the CRC check has to account for how the addresses of functions may change as code is added or removed.  It is not practical for force any function, such as LL$$XOR, to be at a fixed address.

    Thanks and regards,

    -George