Hex File Format Question

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi I am working on a bootloader and an application code for a microcontroller. I have finished both and they generated two seperated hex files. I know I can cascade the application hex after the bootloader hex so that I have a single hex file and burn it into the microcontroller.

The ending part of the hex on the bootloader:

:10287C00000000000000000000000000000000004C
:10288C00000000000000000000000000000000003C
:10289C00000000000000000000000000000000002C
:0400000300001CA934
:00000001FF

And on the application hex:

:10457C00A8080020A8080020B0080020B0080020DF
:10458C00B8080020B8080020C0080020C00800208F
:10459C00C8080020C8080020FFFFFFFF0000020031
:040000031000717DFB
:00000001FF

When I cascade the two hex files, on the bootloader hex, I have tried to
1.)just remove the last line:

:00000001FF

2.) or remove the last two lines:

:0400000300001CA934
:00000001FF

 

I found both method works...I know the meanning of

:00000001FF

is just "end of file" so I have to remove it. But what is the meaning of the second-to-last line?

:040000031000717DFB

 

This topic has a solution.
Last Edited: Thu. Dec 3, 2015 - 08:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a nice help page at Wikipedia about the hex format:

 

http://en.wikipedia.org/wiki/Int...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just remove the single type 01 record in the middle of the file.

 

(the 03 record is irrelevant anyway but I don't see any point in deleting what you don't need to)

 

If you are not confident about joining the .hex files automate the process using srec_cat.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have tried to joining the .hex file manually and it works. If fact I have tried many times for this bootloader, but I do not understand what is the function of the 03 record line. I have tried to remove it or not remove it when joining the files, and both method work.

 

I know it works but I do not want to do something that I do not understand, so I would like to ask what is the function of this 03 record line in this hex file.

 

Thank you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alank2 wrote:

There is a nice help page at Wikipedia about the hex format:

 

http://en.wikipedia.org/wiki/Intel_HEX

 

 

I have read it. In the Wiki, it only generally said the 03 record is "Start Segment Address". But what does it actually means in my hex file for a microcontroller?

Does it means that the code after this 03 record line will be placed at address 0x00001CA9 ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

From Wiki:

For 80x86 processors, specifies the initial content of the CS:IP registers.

 

For Avr processors this line is ignored.

 

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The tools used to generate hex files (for GCC anyway) are generic. There is just one source code for utilities such as objdump, objcopy and so on in "binutils". That same source is used to build x86-objcopy, arm-objcopy, mips-objcopy, avr32-objcopy and our very own avr-objcopy. In theory the "AVR only" bits are isolated into special code for the AVR but something like this 03 record in the generated hex is something that is "seeping through" from the x86/arm/avr32/etc copies of the program.

 

In fact all the handling of ELF and HEX files in the binutils tools is done using a library called libbfd and I'm guessing that in its generic "generate a hex file" code it always decides to put a 03 type record in the output. On system where it does not apply (like AVR) the programming software (Studio, avrdude or whatever) will just ignore it when they read the .hex file. But on systems where it matters it will be used by the tools on those systems.

 

So it's simply an unfortunate consequence of the GCC tools being generic. Such a record has no meaning in the context of an AVR.

 

When you think about it on a PC the record is there to give the initial start address of the code. But on an AVR this never changes. It can only ever be one of 5 fixed values. Usually it is 0x0000 but if BOOTRST is set then BOOTSZ1 and BOOTSZ0 pick one of 4 other possible entry points. The 0x1CA9 or whatever you are seeing there is just a "junk" value. I guess the libbfd code takes some structure value from the ELF and uses that and it either contains junk or a value used for something else inside an AVR .elf file.