GNU Arm Embedded Toolchain

Objcopy Hex format

Asked by Panos

Hello,

I use objcopy to generate a hex file from an elf file.
The problem is that the hex generated is in i16hex format(it uses the Extended Segment Address records)
I would like to export the hex in i32hex format(using Extended Linear Address records)

Does objcopy support this? and how can I configure it? Should I built the toolchain?
I have used the setup filefor installation and I am using windows 8.1

Thank you

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Thomas Preud'homme
Solved:
Last query:
Last reply:
Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said : 		#1

Hi Panos,

I am not familiar with i32hex format but looking at binutils source it seems to be an Intel format. Why are you trying to use an ARM embedded toolchain to generate a file in intel format? What kind of device requires this format?

Best regards,

Thomas

Revision history for this message
Panos (sillentxxi) said : 		#2

The device is a Ble Nano which has a Nordic NRF51 SoC(ARM Cortex-M0). ( http://redbearlab.com/blenano )
The firmware update is done through a bootloader which appears as a Mass Storage Device and all you have to do is paste the hex file generated by the compiler to this virtual flash drive.

If I understand correctly i32hex format is an ihex format variant (see here https://en.wikipedia.org/wiki/Intel_HEX ).
The ihex format is currently supported by objcopy but as far as i can see there are no options about the format variant.
The only difference between the two i32hex format variant and the hex that objcopy generates is the records I have stated previously.

Revision history for this message
Best Thomas Preud'homme (thomas-preudhomme) said : 		#3

Looking at the source of binutils it appears to be perfectly capable of reading and writing the i32hex format. It will emit extended linear address records when it's passed segment base + extended base + 0xffff and passed 0xfffff, ie it will choose the type of record depending on the size of your file. My understanding of the code is that i32hex is a superset of i16hex (ie supports all record type in i16hex + some new record types). More details can be found in bfd/ihex.c in binutils code.

Best regards.

Revision history for this message
Panos (sillentxxi) said : 		#4

Thomas
Thank you for your information and patience.
It took me a while to understand the piece of code you are talking about.

The interesting thing about this implementation is the comment lines
" The extended address record and the extended
 linear address record are combined, at least by some readers. "
Unfortunately my reader seems does not support the combination of both records.

It seems a little awkward combining both and changing from one to another in the middle of the file because according to wikipedia the use of combined records is restricted.

I would prefer it if there was a specific argument such as in fromelf utility of ARM compiler which has i32 format as well as i32combined( https://developer.arm.com/docs/dui0805/latest/fromelf-command-line-options ).

I think it would be nice to have this feature in the next release. It's really just a couple of lines I think.(should we recomend it?)
Anyway for the time being I will consider changing the source file and rebuilding it myself.

Thank you again

Revision history for this message
Panos (sillentxxi) said : 		#5

Thanks Thomas Preud'homme, that solved my question.

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said : 		#6

Hi Panos,

Your last sentence suggest me that you know how to change the code to do what you want. If that is so, I would suggest that you send your patch to binutils community for approval. Note that in order to do that you will need a FSF copyright assignment (see https://gcc.gnu.org/contribute.html#legal which applies to binutils as well). If you cannot sign it or do not wish to, then I would suggest *not* to send any patch, because then someone would need to come up with an alternate implementation for it.

Best regards.