Custom BSL using the crt0.asm for interrupt vector mapping - Is This Feasible?

Johnny Thompson said:

why can't this be done in C?

Normally, you don't know and/or cannto influence the placing alogrithm of the linker. So it's not easy to compile two independent C project so their code won't overlap. It requires some testing and tweaking. Also, some things that must be programmed for a bootloader cannot be done in C. At least inline assembly is necessary.

1) For the vector table, it isn't a matter of crt0.asm. The vectors are store where they are stored. This is a question of the linker script (to be exact: the vector table segment location). The requirement of having the vectors on 0xffxx is a hardware requirement of the MSP and cannot be altered by any software means (except see below).

Your bootloader will likely use interrupts. So the vectors @0xffxx need to point to your bootloader. Then they need to point to the applicaiton later. Forwarding them from your BSL code to teh application will result in additional interrupt latency (the 5 cycles for an indirect jumptable are too much already for some cases). Forwarding all interrupt calls to a fixed location in RAM is possible. It does, however, require adjustment of the stack init code (or maybe the stack would begin right inside your vector table). Also, the vectors are unprotected there. For a tested application thsi is not a problem, but during development it will introduce more possible sources for trouble, and bugs that result in corruption of the vector table are really difficult to track down.

The 5x familyhas a setting that allows moving the vector table form end of first 64k to end of ram. That means, after settign the appropriate config bit, the processor won't fetch the interrupt vectors from 0xffxx anymore. This completely eliminates the additional latency. It doesn, however, still expose the table to corruption.

2) well, not point, just copy it from a fixed (and not utilized) location in flash to the fixed location in ram right before launching the application - while all interrupts are disabled.

So it basically comes down to this:

TheBSL resides as far top of flash as possible. It includes a default vector table that simply makes jumps indirect to a fixed ram location. Then it has its own vector table with its private ISR entry points and of course its own code. The default vector table of course has the reset vector pointing to the begin of the BSL.
When started, teh very firs tthing the BSL does is copying its own vector table to the fixed ram location. Then it can operate.

The application also has a vector table on a (different) fixed location, and begins on the bottom of the flash. When the BSL jumps to the application, it copies the application vector table to ram and jumps through the reset vector of this table. Before doign so, the BSL must disable all interrupts and deactivate all modules it has used, so the MSP will find the MSP as if it were jsut powered up. That's important!

To achieve the above, the linker scripts for both projects need to be altered differently:

for the BSL project, a new segment needs to be created the resides where originally the vector table was. A second segment is needed which contains the indirect jumps to copied ram vector table. The contents of these two segments are static.
The ram segment needs to be adjusted, so that the location where the vector table is copied to later is excluded. The existing vector table segment needs to be moved to a different, fixed location. And last, the existing text segmetn (that contains the code and the init values for the variabels) needs to be trimmed, so it begins as far up as possible while the BSL still fits into it.

On the applicaiton side, the linker script needs three adjustments: The ram segment needs to be trimmeed too, the vector table segment needs to be moved (best is the begin of flash) and the text segment needs to be trimmed so it ends where the text segment of the BSL begins.

This way it should work.

The reason why an assembly BSL is easier is that you can include the assembly BSL easily as a fixed part into each project. So all the linker script changes are identical for each project (not two different modifications for BSL and application) It also makes debugging eaier (as the BSL debug info is included into each project) and some more advantages.

It is not possible to join a C BSL into a project, as then both woudl share a common init code that changes with the application and the BSL wouldn't be static anymore.