EmbDev.net

Forum: ARM programming with GCC/GNU tools Merging two hex files (32 bit ARM controller)


Author: Vinit Bidkar (vinitbidkar)
Posted on:

Rate this post
0 useful
not useful
hi,
   Is it possible to merge two ihex files in one?

   My project has two hex files, 1) Bootloader and 2) Main application. 
Both the firmwares reside in different memory areas. Currently i am 
building these two firmware files in different workspaces and burning 
them one after other.
   I did try few tools from the web like, hex2bin, bin2hex and some 
other custom tools. But nothing worked. Most of the tools were not able 
to open the hex file itself. But i find that there is no problem with 
the hex files as i can read and analyze them using GCC tools like size, 
objdump etc.

Author: docean (Guest)
Posted on:

Rate this post
0 useful
not useful
http://en.wikipedia.org/wiki/Intel_HEX

deleteting the end sequence und then merging the two files should work

Author: Vinit Bidkar (vinitbidkar)
Posted on:

Rate this post
0 useful
not useful
hi,
  thanks for the suggestion, but i have tried this earlier and now again 
on your suggestion. But it is not working. Some times either of the two 
application run or nothing runs at all.

Author: manu (Guest)
Posted on:

Rate this post
0 useful
not useful
I suggest you to try srec_cat which can be found at 
http://srecord.sourceforge.net/ .

It supports joining hex files but I haven't tried it myself, yet.

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
What hex format are you using? There is more than one. Intel Hex is a 
very simple format, and the files can simply be concatenated into a 
single file using a text editor, or if you want to automate the build as 
script:

copy bootloader.txt combined.hex
type application.hex >> combined.hex

This does depend in the last record of the first file being terminated 
with a newline. It also depends on your programming tool correctly 
parsing the hex records, and the hex file generator correctly generating 
the records. The format is fully described here: 
http://pages.interlog.com/~speff/usefulinfo/Hexfrmt.pdf it is likely 
that the files you are using use linear rather than segmented 
addressing, which is a hangover form 16-bit x86 derived.

Also for the files to work, each hex file must have all its data located 
in different location to the other with no common segments (unless 
perhaps if they also happen to contain the same data).

Clifford

Author: Vinit Bidkar (vinitbidkar)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Hi Clifford,
            i did try to paste the second hex file at the end of the 
first one by removing the last line (:00000001FF, which the termination 
indicator) from the first hex file.
            but, if i remove the :00000001FF line then neither of the 
firmware run after burning into the FLASH. (I have placed the 
application hex file first and the bootloader second. I have also tried 
the other way round.)

I have attached the two hex files for reference.

~Vinit

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
>  by removing the last line (:00000001FF, which
> the termination indicator) from the first hex file.

That is not what I suggested. Do not remove the last record! There is no 
such thing as a "termination indicator" in this format; whatever gave 
you that idea? Read the document I linked. That record is likely to be 
essential data.

Clifford

Author: docean (Guest)
Posted on:

Rate this post
0 useful
not useful
look at 8. at your documnet... hex have a "end of file record"

And wiki menas the same

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
docean wrote:
> look at 8. at your documnet... hex have a "end of file record"
>
> And wiki menas the same

My error. My apologies. I am going blind and stupid it seems!

I suggest that you do a flash dump of the working installation, and of 
the non-working combined installation and try and determine what is 
different. Something presumably is being omitted from the burn.

I had a similar system recently where the bootloader uses the start 
address record in the hex file to program an area in the upper page of 
the bootrom so that it can run application code with different start 
addresses, it also programmed a validation signature so that it could 
not attempt to run a failed upload, it is also common to program a 
checksum for teh same reason. Now when combining these images it could 
not work because the validation and start address were programmed at 
runtime, so I manually generated a third hex file to program the 
necessary signature and start address. If you are doing something 
similar, maybe that is the problem.

Clifford

Author: Vinit Bidkar (vinitbidkar)
Posted on:

Rate this post
0 useful
not useful
docean wrote:
> look at 8. at your documnet... hex have a "end of file record"
>
> And wiki menas the same

Hi. I did not understand your comment. Which part of the two of the hex 
file are you pointing at?

Author: Vinit Bidkar (vinitbidkar)
Posted on:

Rate this post
0 useful
not useful
Clifford Slocombe wrote:
> necessary signature and start address. If you are doing something
> similar, maybe that is the problem.
>
> Clifford

Hi Clifford,

I am trying to do a part of what you said you have done mentioned in 
your last post. I have two firmwares 1. Bootloader and 2. Main app. Both 
these application sit in different memory areas. I am not doing any 
thing related to a signature byte at any place.

I have tried following options:

1) Copy two hex files in one, placing one after the other (without 
adding or deleting anything) :- Only the application which is present 
first in the hex file, actually runs. I think this is because the end of 
file record is still intact.

2) Copy bootloader hex files first, strip the end of file record of 
bootloader and then copy the application hex file :- None of the 
application runs

3) Copy application hex files first, strip the end of file record of 
application and then copy the bootloader hex file :- None of the 
application runs

~Vinit

Author: Martin Thomas (Guest)
Posted on:

Rate this post
0 useful
not useful
Since the srecord tools have already be mentioned by "manu": The program 
srec_cat from these tools will help. Win32 binaries of the srecod-tools 
are included in WinAVR.

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
I typed a long answer to this then my PC crashed, so here is the 
short(ish) version. Let me know if you need more information.

If both images run standalone, then they must both have a ROM based 
vector table located at address zero. These will conflict. I would have 
imagined that your programming tool would have failed to write the 
second vector table to a location already programmed, or would have 
simply overwritten the first with the second, but I reckon all bets are 
off, because it is incorrect to have a ROM vector table in both. This is 
what I meant when I said that each hex file cannot have any 
overlapping memory space. Just locating the image in a different 
location is not enough, crt0.s in most cases hard codes the vector table 
at address zero.

Your bootloader must have a reset vector programmed to start the 
bootloader, which then jumps to the application. The application cannot 
have a different ROM based vector table (or in fact one at all). If you 
need a different vector table in the application (i.e. the bootloader is 
not to handle all interrupts), then the application will have to use a 
RAM based vector table initialised at run-time, and must not also have a 
ROM based table.

It is likely then that you will have to modify the application's ctr0.s. 
You may find that there is quite a lot of that start-up that you can 
remove. If you rely on the bootloader to set up system clocks etc., then 
the application need not repeat that, and in some cases doing so may 
fail. Most importantly the application must not create a ROM based 
vector table or attempt to set the reset vector, as this will create hex 
records at locations already covered by the bootloader.

Clifford

Author: Vinit Bidkar (vinitbidkar)
Posted on:

Rate this post
0 useful
not useful
Clifford Slocombe wrote:
> I typed a long answer to this then my PC crashed, so here is the
> short(ish) version. Let me know if you need more information.
>
> Clifford

Hi, due to urgency in other parts of project, i have put this issue in 
backseat. As soon as possible i will revert back.

Clifford: What you have mentioned is very much possible in my case, 
because for building both the firmwares, same crtO.s is being used. I 
will come back with more information.

Thanks
~Vinit

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.