Bootloader & Reset vector

[Eric_t]

Hi, everybody

I am using mc9s12dg256 controller.

I have developed an application and a bootloader in two separate projects. I have used the "HEXFILE" to merge the

two hex files.

Everything works OK but there is an issue with the reset vector.

Reset vector: FFFE

Memory Page: FE00 to FFFF

 When bootloader writes the above memory page, the reset vector is overwritten. This can be a serious problem. 

if something  go wrong during the writing operation, the device will not be able to operate again.

Does anyone know how can I prevent this danger?

Thanks

Nikos 

[kef · Accepted solution]

1. Never update bootloader code using bootloader

2. bootloaders code should be made write protected using NVPROT flash locations

3. Instead of updating primary vector table, make bootloader redirecting vectors either to vector table or jump table defined by application. Primary reset vector should point to bootloader startup routine, which checks validity of loaded code and jumps to application defined reset vector or reset jump table entry.

...

[Eric_t]

Hi, Kef

Bootloader Map:   unpaged memory :C000 - C7FF

Application Map:   Unpaged memory: C800 - FFFF, 4000 - 7FFF

                                 Paged memory:      Page 30 to Page 3D

Reset vector FFFE points to bootloader startup routine. All the rest of interrupts vectors point to application interrupts routines because bootloader does not use interrupts.

As far as I understood I have to redefine interrupt vectors of application project.

Could you give me an idea how can I redefine the interrupt vectors? 

Thanks for your help

Nikos 

[kef]

it is uncommon that bootloader is allocated somewhere inside application address space. Bootloader should be allocated at top of flash and write protected using flash protection byte at 0xFF0D.

Application vectors table should be moved to addresses just below the bootloader. Bootloader should redirect all vectors to application vector table. For how to define vectors table you can look how does Processor Expert generate vectors.c file. 

How to redirect vectors: On new S12X devices there's IVBR register, which allows to move vectors table to other addresses. On older S12 you need to redirect using your code. Since return from ISR routines is done using RTI instruction, you can't call them as C functions from bootloader. You have two choices here. Either turn application ISR routines into regular C functions (which return using RTS instruction) and call them from bootloader ISR's, or use assembler to read application vector address and jump where it point to.

[bigmac]

Hello,

It may be worth mentioning that, for those older devices that do not provide automatic vector redirection, the bootloader itself should be responsible for determining and writing the new vector table location.  The source code should place the vectors at their normal location, as if the bootloader were not present.  This would mean that there are no special provisions required within the source code when using a bootloader.

Probably OK for 16-bit devices, however  the "jump" method is problematic for 8-bit MCUs.  This is because of the PSHH generated by the compiler at the start of the ISR code, with the corresponding PULH just prior to the RTI instruction.  There is potential for overall inclusion of two pushes, but only a single pull - the first push within the bootloader, and the second within the application code.

Regards,

Mac