Newbie on vector relocation - MC9S12XS128.

[JohnBarber]

Hi,

I'm planning a project in which I shall use a primary and secondary bootloader.

My question is, will I have to relocate the vector table?

My device is MC9S12XS128.

Could anyone explain for me, the reasons to relocate the vector table, please. I don't see why it should be done. I need a first lesson on this.

Thanks!

Added p/n to subject.

Message Edited by NLFSJ on 2008-06-10 09:12 AM

[ang]

Hi

Usually Primary bootloader is written into the memory which includes the interrupt vector table area. So if you don't relocate the vector table, it will be with the bootloader & application cannot use it. For the micro controllers, which don't support the relocation of interrupts, we need to write a jump table to the application address.

So Application can use all the interrupts, if you relocate the interrupt vector table to the application area. In XS128, relocation is possible by using IVBR register

Regards

Ang

[JohnBarber]

Hi,

thanks for anwering.

---

ang wrote:

Hi

Usually Primary bootloader is written into the memory which includes the interrupt vector table area. So if you don't relocate the vector table, it will be with the bootloader & application cannot use it. For the micro controllers, which don't support the relocation of interrupts, we need to write a jump table to the application address.

So Application can use all the interrupts, if you relocate the interrupt vector table to the application area. In XS128, relocation is possible by using IVBR register

Regards

Ang

---

But what do you mean with, if you don't relocate the table, you can't use it? It will still be accessable, won't it?

I guess you mean, it will be in protected flash and can't be changed when using the bootloader to download new application firmware.

Is this correct? 

[kef]

That's right, bootloader has to be write protected. Power failure can happer any time. What happens if reset happens while you are in process of updating your bootloader? - MCU won't start again because vectors or part of the program will be erased and not yet updated. So you should even not think about bootloader upgrade in the field. Bootloader should be write protected making erase by code runaway impossible. So you have to use secondary vector table. Using S12X VBR register that's very easy.

What happens if in the process of bootloading new firmware MCU resets? Bootloader should prevent starting partially loaded programs. You should either use checksums to validate loaded programs. Checksum doesn't match - bootloader doesn't jump to uploaded program. Or you could reserve some location in flash or eeprom and make your bootloader erasing this location first, then erase everything else. And write here "upload finished signature" when upload done. Signature doesn't match - booloader doesn't jump to partially loaded program.

Also you should be very careful about your enter bootloader command and erase command. You should be aware that it's not enough for example to send just a byte over SCI to enter bootloader and erase all the flash. It's very likely some unexpected noise can match this single byte. Enter booloader command must be absolutely robust and safe. Even if something failed and MCU did reset to booloader mode instead of user application mode, then bootloader shouldn't automatically erase old loaded program.

[JimDon]

I'm not all that afraid of re flashing a boot loader in the field.

There are many devices, like your pc from example and it's ROM bios, that if powered down during an update required extraordinary measures to repair. I re-flash routers all the time knowing that if things powered down in the middle, I would have to get a JTAG wiggler to recover it - yet it's never happened to me.
Here is another example - if you lose power while re-flashing a Chrysler car, you lose it and have get a special tool and spend half a day getting all back. I know because I have seen it happen.

While it is theoretically true you could lose power at any time, the actual probability over a given small segment of time is very very small. And even if in the unlikely event it does happen, worse case they would have to send the board back to get re flashed.

Which bring up another reason the relocate vectors - field re flashing of the boot loader, so it can still take interrupts while re flashing itself.

[kef]

I'm just trying to protect my customers and then myself from possible problems. I'm not afraid of bootloading. It failed for me just once many years ago. Bootloading was failing because for some unknown reason japaneese localized windows PC was frozing during upload. Of course when PC was getting frozen customer was switching the power off! Different terminal program solved the issue. But if bootload of bootloader was allowed, then I guess we would lose a bit not only on the shipment from Japan and backwards, but also some reputation.

If bootloader is tested and working, then what's the reason to upgrade it? Even if it has some bugs but still allows to upgrade main firmware?

[JimDon]

I certainly agree that it is some thing to avoided if possible.

However, "things happen", requirements change (or features become bugs).
We always think everything is tested , but some how not always true.

Of course you have design the bootloader to be able to up grade itself.