“Normal” ARM cross-compilation for ARM microncontrollers generally consists of three or four steps:
- Use an assembler to assemble the startup code (if it is assembly) into an object file
- Use a compiler to compile any source code into object files
- Use a linker to link the object files into an .elf file
- Use objcopy to convert the .elf file into a .hex file
- Flash the .hex file
It is step #4 that I am unsure about. In the documentation for OpenOCD’s flash write_image command, it states:
The file [type] can be specified explicitly as bin (binary), ihex (Intel hex), elf (ELF file), s19 (Motorola s19). mem, or builder.
It is clear that OpenOCD supports elf files, but I don’t know what this actually means. Is this only supported on some targets? Must the JTAG/SWD adapter provide some sort of objcopy-like functionality for this to work? Is it simply a holdover from the days when OpenOCD did not yet support elf files?
file formats that include address and data like elf, ihex, srec are good to use, I use elf primarily. .bin file doesnt carry the address so you 1) have to specify the starting address 2) objcopy pads gaps between defined areas which can create problems as well as take more loading time, etc.
Using a .bin leaves room for human error on the address. Unfortunately I have had situations where a combination of .elf and openocd will load a the wrong address or at least print the wrong address when loading.
I use .elf files wherever possible. .hex or .srec if the utility does not support elf but supports ihex or srec. And .bin for example when using x/y/zmodem loaders.
I would assume that openocd is layered, that there is a front end that reads the files and by the time it gets to the backend, the jtag or whatever the backend doesnt know what kind of file the data originated from. I dont know for a fact but assume…