Making one object code file from Bootloader project and User Application project

Hi,

   All of the options you mention are a possibility.  As TI-TXT files are easy to edit and inspect, I would simply merge the two files by copying and pasting.  The only thing you must watch out for, is to remove the RESET vector if this is being built in your BSL project (if you forget to tell IAR not to build a RESET vector).  I would also have the BSL TXT at the start of the merged file, simply to make the addresses go from lowest to highest in the final image.

Otherwise, if you weren't building a TXT file, I would chose options #2, but you are correct, it does require making changes to the Linker Command file.

Hello Lane,

thanks for the fast reply.

About this option #2 still. I have used  the Custom Flash-Based BSL provided in slaa450.zip as a base. It's been clear for me to make a library file BSL.r43 and rename the segments with individual segment names by using the IAR XLIB and RENAME-SEGMENT tool to be able to locate the BSL with linker script. When I try to build the user application, with the BSL.r43 library file added to project,  I get the error that I have two entries to "main".

Well, this is pretty obvious since there is entry to "main" in cstartup.s43 file in BSL project. I've tried rename the "main" with something else in BSL project. For examle, I replace the name "main" with "bsl_main" in  cstartup.s43 and BSL430_Command_Interpreter.c files. Obviously, this method is not working, since after renaming I get linking error "Undefined external "bsl_main" referred... "

This is the point when my understanding of the building chain ends. If I rename the "main" with something else, why the linker cannot find the reference anymore?

hmm, I see your issue, it is somewhat more complicated to do than I anticipated.

Probably what would be the absolute easiest thing, is to take the BSL file output, and include it as an absolutely positioned array in your other project.

There is a TI utility to help with this.  In the JTAG programming User Guide (SLAU320) there is an application for use with the JTAG Replicator (I think it's called filemaker).  What this does, is take a TI-TXT, and output a C header file with an array containing the bytes for the txt file.  You can include this header file in your project, position it at the right location, and then get the output you want.

It's slightly indirect, but saves you the issues you mention above.

I cannot speak for IAR compiler&linker but for the ld linker in the GNU toolchain (used bz mspgcc), including the BSL code into the project bears a problem.

Usually, the linker collects all code pieces, then builds a reference tree of which code piece calls which one. Then every codepiece that is not reachable in this tree, starting from the vector table, is eliminated, the remaining code pieces are placed and the references resolved.
Unfortunately, there is no reference to the BSL. So it gets eliminated, unless you add to the linker script that any code in the BSL area shall be marked as referenced even if it is not.

You problem with the main reference is that both, your project and the BSL code are C projects. This means that both are compiled in a way that they need some startup code. This code is implicitely added by the linker and initializes the stack and global variables and then jumps to main.

But this code is only copied once per project and required twice. Just changing the name of the startup function won't work and even if you get it linked without error, you'll likely end up with a main application which does not work.

The basic functioning of the BSL is that there is some specific assembly code which determines whether to enter the BSL and then either does so or jump to the reset vector.
This means the BSL is a separate program, not caring (and must not care!) for the existence of an application with its variables and init code. It has its own init code and variables (maybe linked to the very same ram locations as variables of the main application). If you try to compile them in the same project, it will most likely fail. And if you manage to fixc this somehow, it will still sum the ressource requirements of both, adding the ram requirements of the BSL to the requirements of the applicaiton rather than assuming the ram as unused after the BSL exited.

Unless you write the BSL code itself in assembly language too, including fixed addresses for any variable (so it is not placed by the linker), you'll be better off with the third alternative: compile the BSL as a separate project, strip off the vector table (it is unused for the BSL or, if you need interrupts in the BSL, you'll have to manually create/copy one in RAM and switch over to it) and then include the binary data into the application binary. Or include the binary data of the compiled BSL into your projects source code.

Hello Jukka,

I was about two years ago in a similar situation. In a multi processor system (4 x MSP and one CE CPU) we had to find a solution to boot MSPs via I2C bus and use the same BTL for application sw update. Finaly we decided for your approach 3).

A separate BTL project was built for all MSP as initial load. Any virgin MSP got this BTL loaded first and go his I2C Address as well as its ID (serial number). The application sw was then downloaded by our own BTL. By a command the BTL loads all interrupt vectors of the application into the flash and cause by reset to start the application.

The application itself has a command to call the BTL which restores its own interrupt vectors and runs than as main application.

On the IAR you need to modify applications linker file to reserve space for the BTL and on BTL project modify the linker file to move the code up into the reserved space.

In fact you will have two applications inside the MSP. One is active and one is passive.

The concept works on MSP430F2274 as well as MSP430F5438. It works on IAR and CCE/CCS.

I hope this helps.

Regards

Guenther

PS: Having the BTL loaded first and using the BTL to load the application program was for us a verification that sw update will also work in the field. However you can combine both projects into one combined object file to initialization.