Forums

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

Started by an_anth August 6, 2015
Hi,

I am trying to create a Bootloader for MSP430F1611. Basically I want to
separate Bootloader and Application images so that I can upgrade the
Application image on demand. After reading through manuals, I only managed
to understand how Code segments can be placed at any desired locations in
the memory. However, I didn't find any information on creating two images
meant to be placed at different locations. How should I create a project
to achieve this in an IDE?

I am using CrossWorks for my development. I believe the process will be
similar to all IDEs. Hence I kindly request anyone to help me out with
this problem. And also please be a bit elaborate in your explanation.


Regards,
Ananth






---------------------------------------
Posted through http://www.EmbeddedRelated.com
On Thu, 06 Aug 2015 20:33:33 -0500, an_anth wrote:

> Hi, > > I am trying to create a Bootloader for MSP430F1611. Basically I want to > separate Bootloader and Application images so that I can upgrade the > Application image on demand. After reading through manuals, I only > managed to understand how Code segments can be placed at any desired > locations in the memory. However, I didn't find any information on > creating two images meant to be placed at different locations. How > should I create a project to achieve this in an IDE? > > I am using CrossWorks for my development. I believe the process will be > similar to all IDEs. Hence I kindly request anyone to help me out with > this problem. And also please be a bit elaborate in your explanation.
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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
>Tim Wescott >Wescott Design Services >http://www.wescottdesign.com
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 http://www.EmbeddedRelated.com
On 2015-08-07, an_anth <107532@EmbeddedRelated> wrote:
> > 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. >
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.
> 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 &ndash; 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. >
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. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
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.
  
>You use different linker scripts with the bootloader occupying one part >of flash memory and the application occupying the rest of flash memory.
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.
>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)
For this interrupt problem, I am planning to share some of the interrupts or use a proxy vector table for App.
>Does your bootloader have the ability to burn the application image >to flash ?
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.
>then I use the bootloader to burn the application image each time I >change it.
Does this mean that my idea for the bootloader is similar to yours? Regards, Ananth --------------------------------------- Posted through http://www.EmbeddedRelated.com
On 2015-08-07, an_anth <107532@EmbeddedRelated> wrote:
> >>You use different linker scripts with the bootloader occupying one part >>of flash memory and the application occupying the rest of flash memory. > > 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. >
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.
> >>Does your bootloader have the ability to burn the application image >>to flash ? > > 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. > > >>then I use the bootloader to burn the application image each time I >>change it. > > Does this mean that my idea for the bootloader is similar to yours? >
Conceptually, and based on what you have said so far, it sounds pretty much like it, yes. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
On Fri, 07 Aug 2015 07:05:13 -0500, an_anth wrote:

> 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. > >>You use different linker scripts with the bootloader occupying one part >>of flash memory and the application occupying the rest of flash memory. > > 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.
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'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) > > > For this interrupt problem, I am planning to share some of the > interrupts or use a proxy vector table for App.
<< snip >> 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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
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 http://www.EmbeddedRelated.com