What is the format of .bin output files?

[brianwilloughby9]

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

[Tesla DeLorean]

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''

[brianwilloughby9]

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]

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]

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]

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]

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.

[NCTUser]

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

I need.

Thank you Clive!