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.

CRC calculations of the binary

Other Parts Discussed in Thread: TMS320F28035

Hi All,

I am working on a TMS320F28035 with CCS 4.0 (6.0.1).  I'm looking for a Linker generated CRC for the application binary.  I need to store the generated CRC on the App binary so that later on, I can check this at runtime to verify the integrity of the binary. 

1. What tools does the CCS 4.0 provide for this  ?  Where can I find details and examples ?

2. Where could I find the linker CMD file reference manua( l found chaptor 7 on the "spru513c.pdf" , any other document or examples)?

 

P.S.  I did find a document named "LINKER_GENERATED_CRC_README.txt" on the "C2000 Code Generation Tools 6.0.1" directory.  However it seems to suggest that I need a VCU unit which the F28035 does not contain.

  • Janaka Subhawickrama said:
    What tools does the CCS 4.0 provide for this  ?  Where can I find details and examples ?

    The linker in CGT 6.0.1 has support for this. The document you referenced LINKER_GENERATED_CRC_README.txt has the details. The VCU is not required to make use of linker generated CRC so you can use it with the F28035.

    Janaka Subhawickrama said:
    Where could I find the linker CMD file reference manua( l found chaptor 7 on the "spru513c.pdf" , any other document or examples)?



    That is the main document reference for the C28x linker. In addition, you may also want to check out the TI Embedded Processors wiki which has a lot of FAQs and helpful information on both the processor family and development tools: http://processors.wiki.ti.com/index.php?title=Main_Page

  • Thanks for your prompt reply.

    I used the instructions to create a customised link file to create CRC on my entire application.  CRC worked well I could verify it using some custom code.  However there is one glitch.

    CCS 4.0 (6.0.1) does not seem to like doing CRC on the  ".cinit" section.  It produces an incorrect binary when I include ".cinit" section in the CRC super-section that I define.  I only noticed it because my static variables were not getting initialised properly when the ".cinit" section was included in the CRC.  Extract of my linker script is attached at the end of this post.

     

    Question 1: Is there a better way to do the CRC on the entire app, rather than specifying "*(.text),   *(.cinit)  ...." in a custom section specification as I have done ?

    Question 2: Can you specify specific section types (eg: ".text" sections of all files) in to a custom section in another way than doing "*.text" ?

     

    MEMORY

    {

    .....

        APPCRC      : origin = 0x3E8000, length = 0x000010     /* CRC of the user application in Flash */
        APPFLASH    : origin = 0x3E8010, length = 0x00DFF0     /* Program FLASH used for user application */
        BOOTLDR     : origin = 0x3F6000, length = 0x001F80     /* Bootloader FLASH area that rarely gets erased */

        ....
    }


    SECTIONS
    {

        AppFlashSections    : /* This is my CRC super-section that contains all sections of the App*/
        {
            App_CodeStartBranch.obj(AppStart)
            *(.text)
            *(.cinit)
            *(ramfuncs)
            *(.econst)
        } crc_table(_AppCrc16Value, algorithm=CRC16_802_15_4)
                                > APPFLASH      PAGE = 0


        /*.pinit              :   > APPFLASH      PAGE = 0*/
        ramfuncs            : LOAD = APPFLASH,
                             RUN = PRAML0,
                             LOAD_START(_RamfuncsLoadStart),
                             LOAD_END(_RamfuncsLoadEnd),
                             RUN_START(_RamfuncsRunStart),
                             PAGE = 0

     
        /*.switch             :   > APPFLASH      PAGE = 0*/

        .TI.crctab: { }         > APPCRC        PAGE = 0

    ....

    }

  • First, we recommend that the .cinit section *not* be included in a named output section (or super-section).  This practice may not necessarily be "wrong" (I'm not the expert on that subject), but .cinit is a special section, and placing it under a different section name is a bit dangerous at the least.

    The linker generated CRC is designed to apply to sections, groups and unions.  For various reasons, the compiler does not provide a one-step method to compute a CRC for an entire application at this time.

    One alternative method would be to use crc_table() operators on individual sections, but to use the same table name for each operator.  This would give you a single table containing entries for all your sections.  That would be a larger table, however, than what your method will produce.

    I don't see any problems with your method, with the exception that .cinit should be left out of the super-section.  If a CRC is desired for .cinit, then you can specify a crc_table() operator on the .cinit section, either as a separate table with a different name, or as a separate entry in a single table.  That is assuming you are using --rom_model for your link.

    For question 2, I can't think of an easier method to specify .text sections of all files.  Does that answer the question?

    Regards,

    Steve

    Compiler Support Team

  • Thanks for your answers.

    I have already moved .cinit section out of the named super-section and am doing a seperate CRC on .cinit.  In my verification routine I calculate the CRCs for .cinit and other sections seperately and do the checks.  So far it works well.

    Regards

      Janaka