• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 434 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Compiler/TMS320C6713B: boot table can't be loaded corectly

stephen zhou
Prodigy 40 points
Part Number: TMS320C6713B


Tool/software: TI C/C++ Compiler

Hi:

    I used CCS 3.3.83.20 to build my project and use hex6x to make the boot table. When I load the boot table with my own secondary boot loader, it crashed.

    I checked the map file, found one section's length is not multiple of 4,  and the next section's begin with multiple of 4, which will cause 2 bytes placeholder(filled zero) in the boot table.

    When I load the boot table, the 2 bytes of zero will be used as part of the next section's length, so it's wrong .

    But, one of my colleague used CCS 3.3.38.xx(I forgot) to build my project, all the section's length are multiple of 4. When I make boot table with his .out file, it works well.

    So, is there any diffrence between the 2 CCSs in compiler(6.1.x and 6.0.x)?

    Can I get some documents or datasheet about this?

    Should I make diffrence secondary boot loader for the diffrence CCS?    

    Thank you very much!

    

   

I also checked the two spru186 of this 2 CCS, they are same in boot table file format, as this:

The boot table format is simple. There is a header record containing a 4 byte field that indicates where the boot loader should branch after it has completed coping data. After the header, each section that is to be included in the boot table will have the following:

1. 4 byte field containing the size of the section

2. 4 byte field containing the destination address for the copy

3. The actual data to be copied Multiple sections can be entered; a termination block containing a 4 byte field of zeros follows the last section.

  • 0
    TI__Guru**** 251820 points

    stephen zhou said:
    When I load the boot table, the 2 bytes of zero will be used as part of the next section's length, so it's wrong .

    Another way to think about this ... The secondary boot loader that processes the boot table is wrong in that it fails to account for this padding added by the hex utility.  This forum thread goes into detail about this padding.  

    stephen zhou said:
    I also checked the two spru186

    You make a good point.  The current documentation does not mention that each section is padded out to a multiple of 4 bytes.  But it has always done that.  I recall that older revisions of the book mention this padding.  But I am unable to find any of those old revisions right now.

    A workaround to consider ... In your linker command file, apply the directive palign(4) to force an output section to be padded out to multiple of 4 bytes.  For further detail, search the C6000 assembly tools manual for the sub-chapter titled Alignment With Padding.  With this directive, you can be sure all the padding occurs when linking, and not during the conversion by the hex utility.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 40 points

    Hi George：

        Thanks a lot for your answer and I solve the problem successfully by using the  the directive palign(4).

        There's one more thing I don't understand: why the older linker allocates all the sections  with a multiple of 4 bytes and the newer does not. Is this a 

    coincidence, or certain because of the difference between  their default placement algorithms. Could the older linker always do that?

    Thanks and regards

    -Stephen
  • 0 in reply to stephen zhou
    TI__Guru**** 251820 points

    stephen zhou said:
    why the older linker allocates all the sections  with a multiple of 4 bytes and the newer does not.

    I don't know.  My best guess: The older linker does not intentionally make all the sections a multiple of 4 bytes long.  It just happens to work out that way.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 40 points
    Ok, I've got it.
    Thank's again and regards.