Hex File Format Question

Log in or register to post comments
Go To Last Post
7 posts / 0 new
Author
Message
garypty
garypty's picture
Level: Wannabe
Joined: Fri. Mar 16, 2012
Posts: 69 View posts
#1
Posted by garypty: Thu. Mar 19, 2015 - 02:02 AM
  • 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.

Tags:

AVR Microcontrollers, megaAVR and tinyAVR, solved
Last Edited: Thu. Dec 3, 2015 - 08:08 AM
Top
alank2
alank2's picture
Level: Raving Lunatic
Joined: Thu. Jul 16, 2009
Posts: 2917 View posts
Posted by alank2: Thu. Mar 19, 2015 - 02:38 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...

 

Autoprogrammer:

https://www.avrfreaks.net/forum/wts-standalone-pdiisp-auto-programmers

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99403 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. Mar 19, 2015 - 09:52 AM
  • 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.

Top
garypty
garypty's picture
Level: Wannabe
Joined: Fri. Mar 16, 2012
Posts: 69 View posts
Posted by garypty: Tue. Mar 24, 2015 - 10:08 AM (Reply to #3)
  • 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.

Top
garypty
garypty's picture
Level: Wannabe
Joined: Fri. Mar 16, 2012
Posts: 69 View posts
Posted by garypty: Tue. Mar 24, 2015 - 10:12 AM (Reply to #2)
  • 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 ?

Top
Visovian
Visovian's picture
Level: Raving Lunatic
Joined: Tue. Aug 7, 2007
Posts: 2410 View posts
Location: Czechia
Posted by Visovian: Tue. Mar 24, 2015 - 11:05 AM
  • 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.

 

 

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99403 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
This reply has been marked as the solution. 
Posted by clawson: Tue. Mar 24, 2015 - 11:52 AM
  • 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.

Top