Electronic – Cortex M3 reset handler with vector table relocation

bootloadercortex-m3interruptsreset

I have a system with an STM32F103, which has a bootloader and a main app. Now, the main app is offset from the beginning of the flash to make room for the bootloader, and on cold boot the firmware is entered through the bootloaders reset handler. Then the bootloader does it's thing and eventually starts the main app by calling an entry point defined in the app image. The main app then relocates the vector table via the vector table offset register SCB_VTOR to set up its own interrupts, and everything proceeds from there.

In this case, the main apps reset handler is never called. Further, according to page 35 of the Cortex M3 programming manual, on any reset (cold or soft) VTOR is reset to 0, i.e. it'll point to the bootloaders vector table.

My question: am I right in thinking that the main apps reset handler vector is never called (unless I call it directly myself), i.e. I can just leave it unimplemented/make it assert etc? Or is there maybe some peculiar reset circumstance where the reset handler in the offset vector table might be called?

The motivation for the question is that if I write some "just-in-case" reset handler, I'd certainly like to test it. However, if

  1. the handler is never called during reset, I can't test it (under real conditions, i.e. whatever state the MCU is in when the reset happens. I could of course call it directly, but that isn't quite the same)
  2. if there are circumstances where the handler may be called during reset, then I need to know what those circumstances are, so I can test my handler.

Best Answer

VTOR is reset by the main core reset. All types of hardware reset in M3 will toggle this, including a write to AIRCR.SYSRESETREQ.

This will apply to all implementations of M3.

Nothing prevents your software from using the relocated vector address, but it should be unreachable from the core boot process (similarly, the relocated initial stack pointer is never interesting to the core).

Implementation specific memory banking/aliasing can obviously affect this, but that would apply regardless of VTOR.

Related Topic