• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 83 subscribers
  • Views 212 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.

F29H850TU: c29objcopy - padding when producing binary (-O binary)

Beat Arnet
Intellectual 880 points
Part Number: F29H850TU


Tool/software:

Hello TI Experts,

Could you please provide details about how padding is implemented in c29objcopy? From what I can gather, the binary image is sometimes padded with 0x00, and other times with 0xFF.

Thank you in advance,

Beat

  • 0
    TI__Guru**** 469331 points

    Hello,

    I have brought this thread to the attention of the compiler experts. Please note that due to the local holiday responses may be delated.

    Thanks

    ki

  • +1
    TI__Guru**** 250590 points

    I separate your post into two separate questions.

    1. What causes padding to occur?
    2. When padding occurs, what is it filled with?

    For #1, please see the article An Introduction to Binary Files.  Focus on the part titled Holes in a Binary File.  

    For #2, the default value is 0.  Change that default to 0xff with the option --gap-fill=0xff.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 880 points

    Hello George,



    Thank you very much for your reply. I was unaware of the --gap-fill=0xff  option. Good to know that it exists.

    However, there seems to be more to this.

    I ran two tests with the TI "led_ex1_blinky" project, one with RAM linking, and a second for FLASH linking.

    When linking for RAM --gap-fill does indeed have an effect, and the default is 0x00 as you wrote:

    ${CG_TOOL_OBJCOPY} -O binary ${ProjName}.out ${ProjName}.bin
    ${CG_TOOL_OBJCOPY} -O binary --gap-fill=0x00 ${ProjName}.out ${ProjName}_00.bin
    ${CG_TOOL_OBJCOPY} -O binary --gap-fill=0xff ${ProjName}.out ${ProjName}_FF.bin

    md5 led_ex1_blinky*.bin
    MD5 (led_ex1_blinky.bin) = 579bc756d35ab23f6f1f9ae9a6376c34
    MD5 (led_ex1_blinky_00.bin) = 579bc756d35ab23f6f1f9ae9a6376c34
    MD5 (led_ex1_blinky_FF.bin) = eaeef27043a84d3de6b0037798a80892

    However, when linking for FLASH, --gap-fill has no effect, and the default is 0xFF:

    ${CG_TOOL_OBJCOPY} --remove-section=cert -O binary ${ProjName}.out ${ProjName}.bin
    ${CG_TOOL_OBJCOPY} --remove-section=cert -O binary --gap-fill=0x00 ${ProjName}.out ${ProjName}_00.bin
    ${CG_TOOL_OBJCOPY} --remove-section=cert -O binary --gap-fill=0xff ${ProjName}.out ${ProjName}_FF.bin

    md5 led_ex1_blinky*.bin
    MD5 (led_ex1_blinky.bin) = 760801c0ecf598965b546cabc8ed040b
    MD5 (led_ex1_blinky_00.bin) = 760801c0ecf598965b546cabc8ed040b
    MD5 (led_ex1_blinky_FF.bin) = 760801c0ecf598965b546cabc8ed040b

    Is this intended behavior?

    Thank you again and kind regards,

    Beat

  • +1 in reply to Beat Arnet
    TI__Guru**** 250590 points

    It must be the case that, when building for RAM, there are no gaps in the binary file, i.e. there is nothing to fill.  Does this make sense?  If not, please put the .out file from the RAM build in a zip, and attach that zip to your next post.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 880 points

    Hello George - I just realized that a typo above, now fixed, created confusion.

    I meant to write "However, when linking for FLASH, --gap-fill has no effect, and the default is 0xFF".

    And you are absolutely correct with this image having no gaps at all to fill, and thus they have identical checksums!

    Now all makes sense, and I thank you for your help.

    Beat