Link two application together

look at the bin2hex.exe program.

You can append Intelhex file to existing.

Does this help?

http://www.keil.com/support/man/docs/gs/gs_ca_multipleprojects.htm

I biuld boot loader and application as two targets in the same project. I generate hex output files.

I then strip the last line (the end record) of the boot loader and concatenate the application after the boot loader. This gives the hex file the factory should load into the boards.

Ok, so you use multiple projects?
If I do that, IS just generate two diffrent AFX and HEX file.

I looking for a metode, where I just can build it all. Then I end up with an HEX file containing the bootloader and the application.

I guess the best way is to at the two project in a workspace.

Then run some command line tools (HEX2BIN, BIN2HEX) after build....

Thomas

what is the reason to having two different programs when they are later merged together??

Why not using only one project .. without trouble?

But using hex2bin and bin2hex works ;)

.
.

I have to save and frosen the source code for the bootloader and it's absolutly NOT going to have targets for both in uv3

There're two completely separated applications.. one bootloader which handles 'data' and a second application which is 'data'

I can change the firmware as many I like without touching sourcecode from bootloader!
So in 2, 3, 5 ... years I'm sure I have the sourcecode from the running bootloader(2,3,5years old) and it doesn't matter how ofter the firmware was rebuilded/updated.

The two targets can be 100% disjunct, or they can share common header files or they can share c files. It is up to you to decide.

I normally do not rebuild the boot loader unless I have added new features to it, and in that case this is a new release with a new boot-loader release version. I have a copy of the hex file with the end-of-file record removed. So all that is needed is to concatenate this file with the application hex to produce a full hex file for factory production. The individual hex file for the application gets converted to binary and is used for over-the-air field updates, in which case no boot loader is transmitted.

But a reason to keep the two in the same project workspace is that both boot loader and application is built for a specific hardware, or a specific range of hardware revisions. The boot loader must - just as the application - know how to turn on/off power to needed modules and to know if any serial port should be used for data transfer etc. While an old boot loader should support any newer application, they are still quite much like a mated pair.

It doesn't matter how you separate your code. Any code repository should be able to reproduce your code for the boot loader or the application on a day-by-day basis any number of years back. The question is if you still have a working build machine that can run the same version of the Keil compiler. This is where I hate hardware locks or licensing files.

In my case, the boot loader and application normally share a couple of EEPROM cells, or possibly a flash sector. And in some situations, maybe 16 byte at one end of RAM is reserved for shared data transfers that I don't want to permanently write into EEPROM/flash.

Maybee its because I dont know how to get two seperate application in one project!!?

The bootloader code has to be placed from adress 0x0000
The application code must be placed from adress 0x1000
(Sector 0 for bootloader, Sector 1-7 for application)

How can that be handle from within a single project?

It would be cool to have the bootloader and application code in one project.

How do you handle the application upgrade? Does the bootloader code run from RAM, and then the complete flash is written (Bootloader and application) or is it just the application?

Thomas

Each target can specify a full set of parameters (including processor type, ...)

For LPC23xx projects, I run both from flash. The boot loader gets the flash interrupt vectors. The application vectors gets copied to RAM and then remapped.

The flash is splitted into a small region for the boot loader and two large areas for the application. Any download is performed by the running application into the other application area.

The boot loader may use any amount of RAM and any peripherials it likes. It has a 4kB flash sector where it may check for current configuration. Depending on information found there and contents of two identical-sized application areas, the boot loader makes a decision what to do. It can use a 16-byte RAM area to send a message to the application. The application can use the flash sector to force the boot loader to accept/reject an application area etc or possibly affect baudrate or similar.

A binary with a new application contains both the binary data, and a header with crc32 and version information. The application will not be accepted if not correctly transmitted. And the boot loader will not touch a downloaded application with invalid crc32.

The boot loader will support any version of application, until we possibly decide to create a version with another memory layout, but we currently have support for two (or maybe it is three) different memory layouts in the applications and the boot loader. The different memory layouts affects how much flash space that is reserved for application code, and what flash sectors that are reserved for application data (configurations, alarm states, log info, ...)

The application is able to pick up the boot loader version, so it will know how good the boot loader is. In theory, the application has support to also replace the boot loader, but this is a dangerous step that we do not want to use unless the alternative is to manually visit all units. A failed boot loader update will (!) result in a need to send the unit to a service center since there is no way to perform an atomic switch of the boot loader.

That was a quick summary - the full requirements and test specification is quite a bit longer :)

I see..

But how doi I setup, so the bootloader and application is handle in the same project?

The bootloader source code must be build to a specific flash sector.
The application source code must be build to another flash area.
The application must be build to a BIN file
The bootloadet and application must be build into a merged HEX file.

Is that possible? Or is the hex2bin/bin2hex the best way of doint this?