Vector table relocation in bootloader application

1
votes

I've written a bootloader application for NXP Kinetis microcontroller. Following are the things I did to do the same: 1. Created a bootloader application in CFlash addresses 0x0000 to 0x8000 2. Created my main application code from addresses 0x8000 to 0x1FFFF

This code is working fine. Now my doubt is, I have ISRs placed in both bootloader as well as main application code and didn't use any ISR vector relocation. Is it necessary to relocate the vector tables in main application?

PS: I may not be facing the issue just because the ISRs in both the apps are same.

2
cembeddedmicrocontrollerbootloadernxp-microcontroller
where is your vector table and what does it point to? if not at the post reset value then clearly you need to move it (if possible, depends on the core). - old_timer
@old_timer The question is about all the interrupt vectors like timer, adc, uart etc. Vector location is stored at address 0x0000. - Arun Kumar
right, so is my question back to you...you did read on how the processor works right? what part of that did you not understand? This not an nxp thing but a processor core thing. - old_timer
nxp kenetis is too generic, which core you have determines what is available... - old_timer

2 Answers

2
votes

On most modern MCUs the vector table relocation is not required, as the vector table base address can be specified as a parameter when compiling an application.

If your target's doesn't have such feature and the vector table is in the bootloader are 0x0000 to 0x8000 then you will need to relocate the vector table for the application so that an interrupt occurring in the application results in jumping to the correct handler.

1
votes

Although I don't know the specifics of a Kinetis microcontroller, the following is based on general behavior of other Freescale/NXP controllers.

A bootloader is meant to allow you to update your firmware. (Otherwise, you don't need one.) And, a bootloader has to be kept in protected memory to prevent accidental erasures. By protecting the bootloader you also protect the vectors. So, you can't update the vectors anymore.

Unless you go to extremes to guarantee each firmware update will have the ISR code start at the exact same address as in the previous version(s), you'd rather be able to have ISRs move freely in the address space. That's where vector relocation or redirection comes in to play.

Currently, you have both bootloader and app use the same addresses in both sets of vectors, and everything works fine.

As soon as you update your firmware to another version where the ISR entry points most likely have moved address, your code will stop working because the MCU/bootloader will be sending the ISR events to the wrong addresses.

If you enable/implement vector relocation/redirection, the original bootloader vectors will effectively be ignored, and the relocated vectors will be used. Since these are updated along with your application, no problem.

There are two methods for vector relocation. One is hardware based (has the advantage of no ISR call overhead) and the other is software based (some minimal overhead but can be implemented even in microcontrollers that have no hardware vector redirection available).