Vector Table - Use Multiple tables or Relocate?

[ignisuti]

I working on creating a bootloader and see that the standard appears to be to relocate (copy) the vector table before jumping into application code.

What about instead maintaining two copies of the vector table? In my case, I'd have a vector table with reset address and no interrupts for the bootloader and then a 2nd vector table with all my various interrupts for the application. The 2nd table is located immediatly before the application code and is over-written at the same time the bootloader is updating the application code.

I see the multiple table approach as booting slightly quicker and preserving more RAM since the 2nd table is stored in ROM. Can you think of any disadvantages? Is this a common thing that developers already do?

[mjbcswitzerland · Accepted solution]

Hi

The Cortex has a flexible interrupt controler whos interrupt vector table can be pointed to almost any location (Flash/RAM).

This means that you can have multiple interrupt vector tables or you can enter functions in a single one in SRAM.

The advantage of the SRAM based one is that it is easy to change individual interrupt handlers at run time without having to change the whole table. If minumum SRAM use is a requirement relocating fixed Flash tables may be preferred, but the SRAM based method is certainly simpler to maintain.

Regards

Mark

P.S As comparison with Coldfire - the interrupt vector can be located only to 2Meg boundaries (if I remember correctly). Since the internal SRAM and internal Flash is generally much smaller than this there are only two choices - start of FLASH or start of SRAM. In the case fo Coldfire boot loaders it means that you have to use an SRAM based table or else invent a jump table method from fixed vectors in the boot loader - SRAM being of course much easier to maintain again.

[ignisuti]

I went ahead and gave the multiple vector table approach a try and it seems to work well for my needs.