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.

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

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

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