msp430f5510: info ram for storing virtual vectors table

Giovanni Casano said:

I would like to ask you if the "info" flash area is good for storing such a table.

Usually, the values of these vectors are specific to the applicaiton you load (if not, you don't need them at all), so why not just providing the table with the applicition itself.
E.g. mapped to its start.
The main reason for info flash is that it can be kept durign a main flash mass erase, and provides smaller flash segments, so for updatign data in it, less ram is required to buffer the data that is not changed, soit can be restored after a segment erase.

But of course you can place the virtual interrupt vectors there. It's a place as good as any other. Just that updating them toghether with the applicaiton will require a bit more handling effort.

Dear Jens-Michael, I am referring to the virtual vector as reported here: http://processors.wiki.ti.com/index.php/BSL_(MSP430)#General_Custom_BSL_FAQ

It is not clear how to map interrupt vector from start of application: could you be a little more verbose?

Thank you in advance.

-g

PS: does that means I should copy the interrupt functions pointers from my application, in the interrupt vectors each time the application is started?

and after the bootloader is restarted, should I rewrote the BL interrupt functions pointers, in the interrupt vector location?

Giovanni Casano said:

It is not clear how to map interrupt vector from start of application: could you be a little more verbose?

1) never erase the 'real' interrupt vector table (so the reset vector always points to your custom BSL) and the custom BSL.
2) have all 'real' interrupt vectors point to a handler
3) have all handlers jump to the application ISR
4) put the address of the function ISRs where the handlers can find them.

Example:

Interrupt vector table entry: 0xFE00
FE00: handler: BR $8000
8000: address of ISR

So all you have to do then is to ensure that the address of the current applications ISR is always at 0x8000. This can be done by relocating the vector table segment in the application projects linker file from 0xFF80 to 0x8000.

However, if the BSL itself also uses interrupts, things get trickier. During BSL operation, the 'secondary' or 'virtual' vector table at 0x8000 needs to hold the BSLs vectors. SO the BSL on begin of an update (and before using any interrupts) needs to clear 0x8000,copy its own vectors there, and then keep the applications content there in RAM until the update is done, and update the area at 0x8000 as last, when no BSL ISRs are active anymore.
Alternatively, on MSPs with optional RAM vector table, the BSL might copy its interrupt vectors to ram and switch to ram vector table. And before starting the application, it switches back to ROM vector table. This is safer than holding the application vector table in ram :)
A third way could be to expand the above handler for all BSL-required interrupts, so that the 'handler' actually is the BSL ISR, that checks whether the BSL is active and if not, jumps to the application ISR. This adds to the latency for these interrupts, but makes things much easier to program. :)