• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 78 subscribers
  • Views 137 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.

MSP430FR5994: .bin file format

Fred P
Expert 2100 points
Part Number: MSP430FR5994

Do you have some documentation about .bin file format generated by msp430-elf-objcpy.exe?

I am trying to figure out by myself....

Building of a MSP430FR5994 having 256KB FRAM, I was expecting a 0x40000 bytes file that maps right into the FRAM. 

It appears not to be the case.

Referring to the .ihex file generated during the same build, I can clearly see the beginning of FRAM content appears at 0x1500 in the .bin file.  0 to 0x14FF are all 0. What's that stuff?

If there is extra stuff at the beginning, then the file should be that much longer. That is not the cas with my file (0x3F482 bytes long).

Obviously, the .bin file omits something.  I imagine the very end of FRAM, if not to be programmed (unused), is omitted.  Right?

Thanks for your assistance.

  • 0
    Guru 21145 points

    From the man page:

     ‘objcopy’ can be used to generate a raw binary file by using an
    output target of ‘binary’ (e.g., use ‘-O binary’).  When ‘objcopy’
    generates a raw binary file, it will essentially produce a memory dump
    of the contents of the input object file.  All symbols and relocation
    information will be discarded.  The memory dump will start at the load
    address of the lowest section copied into the output file.

       When generating an S-record or a raw binary file, it may be helpful
    to use ‘-S’ to remove sections containing debugging information.  In
    some cases ‘-R’ will be useful to remove sections which contain
    information that is not needed by the binary file.

  • 0 in reply to David Schultz
    Expert 2100 points

    Your answer kickestarted my troubleshooting.

    After a lot of trials and error, I figured out what's going on.

    Once I strip all and every single sections between 0x2B00 and 0x4000, I get the expected 256kB file that should be the exact FRAM content.

    The removed sections are RAM and irrelevant in our binary file for production.

    The root cause is NOLOAD attribute missing in .ld file.

    Lessons learned.

**Attention** This is a public forum