Can't debug when loading BSL and main application into flash

How do you 'tell' the MSP to use the main reset/int vectors?
It's nice that you told teh linker to put them elsewhere, btu the MSP doesn't care for linker scripts. It always takes the vectors from 0xffe0+.

How does your bootloader call your application?

Hey Jens,

Keep in mind that I'm new to MSP430 development and have never gone into this level of detail on the linking and execution of the code before.  I can appreciate that there are many different ways to develop a custom BSL application so in posting here in the forums I'm hoping to not only enhance my knowledge on a particular approach but also to get some advice on some other approaches.

So for my current approach my plan is to have the bootloader application "own" the reset and interrupt vectors at 0xFFE0.  On startup the bootloader app would execute by default.  The bootloader application will check a flag residing in flash (probably inside the information section of flash at 0x1000).  This flag will tell the bootloader whether to jump to the main application (residing at 0x1100) or to remain in the bootloader and wait for a programming command over I2C.  In the bootloader, the interrupt handlers will all check this bootloader flag as well and either execute the bootloader handler or jump to 0xD7E0 to where the main application interrupt handlers reside.  This will add latency to the handlers but shouldn't be an issue for this application.

As mentioned, I'm interested in feedback on this approach to a custom bootloader and alternative approaches, but my original post was more on some IDE configuration issues and how to get multiple programs loaded and running using CCS.  When I load the main application first and then the bootloader application (with no jump right now) I'm not getting anything happening on startup.  I'm using the debugger interface on CCS to load the programs.  Is there a separate stand-alone programming utility that has more control on how and where to program things into flash.  I still think there is a gap in my understanding of how the MSP430 builds, links, and programs code.

I appreciate any assistance.

Dan Closson said:

So for my current approach my plan is to have the bootloader application "own" the reset and interrupt vectors at 0xFFE0.

Fine

Dan Closson said:

On startup the bootloader app would execute by default.  The bootloader application will check a flag residing in flash (probably inside the information section of flash at 0x1000).

Fine.

Dan Closson said:

This flag will tell the bootloader whether to jump to the main application (residing at 0x1100) or to remain in the bootloader and wait for a programming command over I2C.

Not so fine. YOur assumption that the code entry point is 0x1100 is only valid if your application is a non-relocatable assembly application. In any othe rcase, the linker will set the entry point location based on a lot of factors. That's why there is such a thing as a reset vector instead of just running from start of flash.

Dan Closson said:

 In the bootloader, the interrupt handlers will all check this bootloader flag as well and either execute the bootloader handler or jump to 0xD7E0 to where the main application interrupt handlers reside.

Same problem. But by 'moving' the interrupt vector segment in the linker script to this location, it is safe to expect the vectors there. But why 0xD7E0? Is your bootloader so large that it needs the area from 0xD800 to 0xFFE0?
For the itnerrupts that aren't used by your bootloader (msot of them), the 'ISR' can just be an indirect jump, e.g. MOV &0xD7E0,PC. No need to check a flag. If the bootloader doesn't need these interrupts, they are not active in bootloader mode, or if they are, then the applciaiton has enabled them and is obviously running. This reduces the latency.

But you're right, for these ISR that the bootloader uses, you'll need to check whether the bootloader is active or not. And you need to disable these interrupts before you call the application. However, in most cases you can as well do a polling of the peripherals and do not need any interrupts at all inside the bootloader.

Dan Closson said:

my original post was more on some IDE configuration issues and how to get multiple programs loaded and running using CCS.

Of course you can store multiple applicaitons in an external memory and load them through your bootloader from memory into flash as required (e.g. select by a jumper settign on GPIO pins). When started, teh loader checks the currently loaded application and compares it to the jumper settings on soem port pins. If it matches, fine, if not, it loads the 'proper' application from external memory. THis allows for a multi-purpose device even if not all applications fit into the internal flash into a 'super-application'.

However, loading an application from external memory takes quite some time, and power.