• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 84 subscribers
  • Views 519 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Linker generated CRC - Order of CRC tables

Harsha Dsouza
Prodigy 180 points
Part Number: TMS320F280049

Hi,

I'm trying to generate CRC using the linker directive crc() operator for each flash sector of my app code and reading the same in the bootloader application and verifying it during the bootload process. I have placed the CRC table in a separate memory location which is placed above the application code. I'm able generate the CRC table and read the same but I found that the tables are placed in the memory at random i.e. they are not continues. My approach was to receive a sector of data verify its CRC and then proceed to the next sector, but since the CRC tables seems to be not contiguous I always end up having a CRC error as the C generated CRC in the bootloader application is calculated for contiguous sectors. I found that the CRC tables are not contiguous by loading all the CRC tables into an array and checking the address field of each table. 

My question is am I right in assuming that the linker will generate the CRC and place those tables in memory in a non-contiguous manner? Cause I read this in one of the example in spru513w;

In Example 8-9 the same identifier, _my_crc_table_for_a1_and_c1, is specified for both a1.c.obj and c1.c.obj.
The linker creates a single table that contains entries for both text sections. Multiple CRC algorithms can occur in
a single table. In this case, _my_crc_table_for_a1_and_c1 contains an entry for the text data from a1.c.obj using
the default CRC algorithm, and an entry for the text data from c1.c.obj using the CRC16_802_15_4 algorithm.
The order of the entries is unspecified.

  • +1
    TI__Guru**** 244280 points

    There are two different ways the linker may compute the CRC.  One is based on sections, and uses the operator crc_table().  The other based on memory ranges, and uses the operator crc().  The answer to your question is roughly the same in each case.  Because you quote ...

    Harsha Dsouza said:
    Example 8-9

    ... and that is related to crc_table, I presume you use crc_table.

    When crc_table is used to create a table for an output section, the CRC table itself is placed in a different output section named .TI.crctab.  If crc_table is used multiple times to create multiple tables, there is no method for controlling the order of these tables in the output section .TI.crctab.  Note crc_table can also be used to put the CRC for multiple output sections in the same table.  In such a case, there is no method for controlling the order of these CRC records in the same table.

    All that said ... Please consider using the CRC examples in C2000Ware.  That is likely to work out better than building your own solution from scratch.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 180 points

    Hi George,

    Thanks for the quick reply. I did use the CRC examples from C2000 and have reached this far customizing as per my requirement. I started by generating CRC using the VCU function call and the C code present in the appendix of the assembly language user manual, I found that only the CRC using the VCU function call was not matching to the linker generated CRC, I did raise this question but did not pursue it cause the C code was working and serving my purpose.

    Anyways this does answer my question and thank you for clarifying it, I just have to employ a small logic to get around it.

    Thank you.