Creating multiple images (Boot & App) in a project (IDE: CCS/IAR/CrossWorks) ?

I can't answer your whole question, but I strongly suggest that you make it TWO separate projects -- one for the boot loader, and one for the application.

From experience, I also suggest that you keep the bootloader small, because each line of code is an opportunity for a bug. Make a utility that tacks a CRC to the end of the application code space, and make the boot loader verify the CRC before it runs the application (because downloading the wrong code, or half a load, is a bitch). Make a physical "escape hatch" out of a spare processor pin, so if the application code is flawed you can boot to "safe mode".

And finally -- check to see if the processor already has a boot loader. If it does, maybe you just want to use that.

Hi Wescott,

Thank you for the reply. I have already considered most of the points you have mentioned when I came across Bootloader available for other MSP430 MCU.

If you make it two separate projects won't some of the segments be overwritten? How do you make sure all the segments generated by compiler for each project to be separated in memory space? This has been the hurdle for me presently.

I have presently tried placing the CODE segment separately. And I am confused how to deal with other segments when you are having two projects.

TI has an Application Report (SLAA600A): "MSPBoot ? Main Memory Bootloader for MSP430". The MCU code provided and the IDEs to which it is provided (IAR & CCS) for is also different than mine. As you have suggested they separated projects for Boot and App. I don't know how to port it to my MCU and also could not understand how each image can be burned in the same MCU.

Regards, Ananth

--------------------------------------- Posted through

You use different linker scripts with the bootloader occupying one part of flash memory and the application occupying the rest of flash memory.

I'd also recommend making the bootloader use any devices in polling mode so that you don't have to worry about clashing interrupt vectors either. (IIRC, the MSP430 uses flash based hard coded interrupt vectors)

I also very strongly second Tim's suggestion about making the bootloader and application two seperate projects.

This depends on the abilities within the tools you use to burn the flash image. Ideally you will have two flash images, one for the bootloader and one for the application.

Does your bootloader have the ability to burn the application image to flash ?

I have a bootloader I wrote for the PIC32MX. It can either execute the existing code stored in flash or it can download a new image from the development host and run it from SRAM or burn the new image to flash (depending on how it was linked on the development host).

I use my programmer to burn the bootloader as a one-off exercise and then I use the bootloader to burn the application image each time I change it.

Simon.

Hi Simon,

Thank you for your suggestions.

As of now I have not implemented anything completely. Just gathered ideas which might work after some extensive studies.

I have to figure out how to create 2 linker scripts in CrossWorks. The manual is not containing enough material and I could not find any related solutions in their forum. When I contacted them they said they won't give support for Educational Licensee.

For this interrupt problem, I am planning to share some of the interrupts or use a proxy vector table for App.

My design for the Bootloader will be like this: Once I get a message from wireless source for updating the App, I collect all the packets, check the integrity of the image and then write into a predefined flash location. Later on I just jump to that image location for execution.

Does this mean that my idea for the bootloader is similar to yours?

Regards, Ananth

--------------------------------------- Posted through

As I'm CLI based, this isn't an issue for me so I can't offer you any specific advice.

However, in general terms, can't you have a custom linker script per project in your IDE ?

If so, you just use one linker script for your bootloader project and another linker script for your application project.

Conceptually, and based on what you have said so far, it sounds pretty much like it, yes.

Simon.

If the linker script uses gnu format (which it certainly will if your tools are a port of gcc) then you just need to find documentation on the gnu linker format. It's still pretty obscure, but if you have a script for your processor and you know the starting and ending addresses of the flash memory, much will become clear.

I strongly suggest keeping the app as independent of the boot as possible

-- preferably you want to have just one entry to the app.

Some processors allow you to relocate the vector table: if yours does, then right before you branch to the app, relocate the vector table. Better, some processors will allow you to relocate the vector table and it'll STAY there for a soft reset -- in that case (and assuming that the reset vector is in the table), relocate the table and do a soft reset.

That way the only thing the boot code has to "know" about the application is where it puts its vector table.

Hi,

Thank you for all the useful info.

I couldn't find enough docs to work in CrossWorks and in their forum they refused to give at least a small tip on my linker related doubts. Hence I have decided to switch to CCS now.

I am trying to port the already available MSPBoot project to my MCU. It has all the requirements that you guys have mentioned. I need to strip off all the unnecessary modules and add the wireless module to make my idea work. The linker command file looks complicated. However, I am understanding it better with the help of all the available docs. Hope I will finish it before my deadline this week.

Regards, Ananth

--------------------------------------- Posted through