What are the uPy differences/implications between .bin, .hex, .elf, .map, .dfu firmware?

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
Post Reply
androiddrew
Posts: 18
Joined: Sat Jan 23, 2021 7:24 pm

What are the uPy differences/implications between .bin, .hex, .elf, .map, .dfu firmware?

Post by androiddrew » Fri Jul 30, 2021 1:10 pm

I am looking at https://micropython.org/download/all/ for the ESP32 in particular, but really my question is more general about all the artifact types. What are the differences between .bin, .hex, .elf, .map, .dfu artifacts? I can Wikipedia the file types and get the idea that yeah .bin is a binary file, .hex is hex etc, but why are there multiple formats available for boards? When do I select one option over the other? Are there memory implications with using the larger .hex to flash my board over a smaller .bin file?

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: What are the uPy differences/implications between .bin, .hex, .elf, .map, .dfu firmware?

Post by dhylands » Sat Jul 31, 2021 1:38 pm

.bin is raw binary data with no headers or other meta data to indicate what address it should be stored at.

.elf files are the direct output of the linker. They potentially contain lots of data not required for programming/flashing. I.e. they can contain symbolic debugging information, etc. The elf format is fairly complex.

.map files are produced by the linker to tell you where all of the symbols are located in memory. These can tell you how many bytes each function or global variable takes up. .map files don’t have enough information in them to program a device.

.hex files are slightly more advanced than .bin files. The .hex files are stored using ASCII format and not only contain the binary data but also the address that the binary data is supposed to stored at.

.dfu files are also slightly more advanced than .bin files. Each region of memory has a small header with some meta data (I.e. address, length plus some additional fields). The data itself is stored in binary format.

.elf, .bin, .hex, and .dfu formats can all be used for programming a device. Which one to use depends on the programmer being used.

JennaSys
Posts: 33
Joined: Tue Jul 15, 2014 8:29 am
Location: Southern California, US
Contact:

Re: What are the uPy differences/implications between .bin, .hex, .elf, .map, .dfu firmware?

Post by JennaSys » Sat Jul 31, 2021 4:44 pm

Your post should be pinned somewhere or added to a wiki. Great information!
John Sheehan

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: What are the uPy differences/implications between .bin, .hex, .elf, .map, .dfu firmware?

Post by jimmo » Wed Aug 04, 2021 4:52 am

androiddrew wrote:
Fri Jul 30, 2021 1:10 pm
When do I select one option over the other?
As Dave said "Which one to use depends on the programmer being used."

As a quick guide:

- ESP32 / ESP8266 will typically always use a .bin file and esptool will indicate where to program it.

- Many STM32 boards have USB DFU bootloaders, and the programmer software you use will accept either a .dfu (dfu-util, pydfu), or a .hex (STM32CubeProgrammer), or a .bin. (Confusingly, even though the programmer uses DFU (or DFUSe) to talk to the device bootloader, it may support multiple file types).

- DAPLink (e.g. micro:bit) and STLink-based boards can present as a mass storage device, which can be programmed with a .hex file (by dragging the .hex file to the device).

- Debuggers (e.g. GDB) can load .elf files.

It's also worth knowing about the .uf2 file format, which is used for uf2 bootloader (very common on CircuitPython boards, as well as the RP 2040/Pico). It works like a .hex file in that you drag it onto the USB Mass Storage drive, but internally it's a binary format more similar to .dfu).
androiddrew wrote:
Fri Jul 30, 2021 1:10 pm
Are there memory implications with using the larger .hex to flash my board over a smaller .bin file?
Like Dave said, they all contain the same data, it's just about whatever your programmer/board needs (and you might have multiple options).

(The one exception is that the .elf contains more information that isn't necessary for runtime)

Post Reply