Skip to main content
brianwilloughby9
brianwilloughby9
Associate II
October 1, 2015
Question

What is the format of .bin output files?

  • October 1, 2015
  • 5 replies
  • 5259 views
Posted on October 01, 2015 at 21:13

I'm working with the STM32 Bootloader, and I see that the .hex output from my Eclipse build has reasonable addresses. When I look in the .bin output, though, the contents don't seem to match what I expect. Is the .bin file a raw image of bytes that should be programmed into Flash starting at address 0x08000000? Or is there some sort of loader format that the data is structured into?

I'm not sure whether this is an Eclipse question, a generic ARM question, or if it's specific to the STM32 tools. If nobody has the answer, I'd at least appreciate a pointer to the right forum, if another is more appropriate.

Thanks!

#arm #eclipse #bin
    This topic has been closed for replies.

    5 replies

    Tesla DeLorean
    Tesla DeLorean
    Guru
    October 1, 2015
    Posted on October 01, 2015 at 21:53

    It's a format-less raw image of bytes. Reflects the data exactly as it is in FLASH, at the chosen address. No address information is passed or inferred.

    .HEX files can be sparse (have holes), and non-linear (jump about)

    Now you can package binary files around some headers, etc, but you have to define how you do that yourself, and it becomes a different type of ''binary file''

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    brianwilloughby9
    brianwilloughby9Author
    Associate II
    October 1, 2015
    Posted on October 02, 2015 at 00:33

    Thanks clive1,

    My Eclipse build is running the following two commands:

    arm-none-eabi-objcopy -O srec --srec-len=32 --srec-forceS3 ''gp.elf'' ''gp.s37''

    arm-none-eabi-objcopy -O binary -j .text -j .data ''gp.elf'' ''gp.bin''

    ... but the contents (at the start) do not match. The SREC version looks correct, because it has a Stack Address, Reset Address, and a series of Vector addresses - exactly what I would expect at the start of the Flash image. The BINARY version starts with completely different data.

    As I write this, I wonder if the .text and .data restriction is excluding the vector table, which might explain the differences. I'll look into whether the vector section has a different name (other than text or data), and see about adding it if it is missing.
    brianwilloughby9
    brianwilloughby9Author
    Associate II
    October 1, 2015
    Posted on October 02, 2015 at 00:43

    Ok, looking at the .map file, it's clear that the .data section does not belong in Flash at all, and the .text section is not the only section that belongs in Flash.

    It seems that I need a command line for objcopy that creates the exact Flash image without discarding anything or adding extraneous data.

    Any hints? I'm still researching, but it seems that this would be a commonly-needed objcopy option.
    brianwilloughby9
    brianwilloughby9Author
    Associate II
    October 1, 2015
    Posted on October 02, 2015 at 01:04

    I turned off the checkboxes in the Eclipse Tool Settings that were adding those -j options, and now the .bin seems to match the .srec file.

    Looks like I partly answered my own followup questions, but wanted to put the results here in case others run into similar problems.

    NCTUser
    NCTUser
    Associate II
    January 8, 2019

    Hello,

    I am working on a bootloader as the op and I would like to

    choose a proper binary format to download. As Clive Two.Zero

    mentioned binary format is a headerless continous raw flash

    image.

    What happens if the output sections are not continous? For

    example the application begins at low flash addresses and there

    are other data at the end of the flash too. (There are some "nameplate"

    data which contain softwareID information always at fixed

    address at the end of flash.) In this situation will I get an almost

    flash sized (128K) binary image and the hole between the

    application and the softwareID will filled with 0xFF-s?

    (Sorry, I am newbie with SMT32 toolchain/linker at the moment

    I dont know how to try it.)

    I migrate a working bootloader project to STM32 from other

    MCU architecture and that architecture's hex converter

    provided a binary "Boot Table Format" which was a sequence

    of blocks. Each block had a header (destination memory address

    and data size) and the data, so the memory holes did not cause

    problem.

    Can I generate with the GNU toolchain (TrueSTUDIO) similar

    binary format, which contains similar blocks? I know this topic

    is old, but I appreciate any answer or advice.

    Tesla DeLorean
    Tesla DeLorean
    Guru
    January 8, 2019

    Well in Keil with sparse memory regions the ELF processing tool will output multiple .BIN files in a directory. Other tools create large blobs with big voids in them.

    When packaging firmware images here I can take a .BIN, .HEX or .AXF/ELF file and apply whatever header and authentication I need, and compress and encrypt as necessary. I usually have this as a post-link step.

    The formats of .HEX and .ELF files are well defined/documented.

    ST has a multi-region binary DFU format where the data is wrapped with header and integrity information. I posted a HEX2DFU tool some time back.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    NCTUser
    NCTUser
    Associate II
    January 10, 2019

    I did not know about the DFU format, it is very similar what

    I need.

    Thank you Clive!

    Terms & ConditionsAccessibility statement