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.
http://en.wikipedia.org/wiki/Intel_HEX deleteting the end sequence und then merging the two files should work
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.
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.
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
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
> 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
look at 8. at your documnet... hex have a "end of file record" And wiki menas the same
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
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?
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
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.
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
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