Does not Reset Handler move along with NVIC vector table?

Question

My board: STM32F407G-DISC1 (based on STM32F407VGT6 microcontroller)

See reference manual. (pages around 371 are related)

My understandings

Each interrupt service routine is located in a memory address, and this memory addresses are hold in NVIC vector table. Normally, we have weak declarations of those interrupt service routine(callback) functions in startup.s file. So, overwriting them in a .c file, in main.c for example, will be enough to use them. Those names are defined strictly, and one have to use same names, for example : EXTI0_IRQHandler()

However, we also have VTOR, Vector Table Offset Register, by which I can relocate vector table to another memory region, and can use my customly defined callback functions with different names by writing their memory addresses(function address) to the new memory location of the corresponding interrupt vector.

So far, everything is fine, I confirmed that when I relocated the vector table by VTOR, the old names are useless unless, i.e, just defining an ISR function named as EXTI0_IRQHandler() is not sufficient without further work(writing its address to new vector table location for EXTI0).

---

Question

At this point, one thing confused me, even I migrate/move the NVIC vector table, pressing the black button(reset button) on the board resets the microcontroller still. But I would expect reset not to work since the ISR pointer for Reset_Handler() is not defined/found in the new location of the vector table.

My guess: Reset_Handler() does not move with NVIC vector table, always located at 0x0000 0004, and its definition is in startup.s. So, it will be the same.

I assume I have some conceptual misunderstanding in this. Can you point what is wrong with my thinking?

Answer 1

The point of a hardware reset is to reset the state of the system.

Thus any runtime change to the vector dispatch mechanism state is negated by the reset before the vector table entry is used.

Think about it this way: if reset didn't undo mistakes, it wouldn't be much of a reset... (Granted, mistakes that change flash or option bits are another story)

Given this, it could be argued you cannot actually relocate the reset vector and initial stack pointer entries, but only seem to, as the change would be reverted before they are actually used by the processor hardware reset sequence. However, when a software bootloader executes a target program, often the target program's initial stack pointer and reset vector are read by bootloader software and used to set up and branch to the target - technically in that case the locations in the vector block are just being borrowed and not used by the hardware. But since reset resets the relocation, arguably you cannot actually relocate those two entries in hardware effect, only seem to as they ride along with the rest of the table that can have its purpose utilized by hardware in an alternate location.

Note chips that have boot mode select pins and option bits can map different physical memory to the location where the vector table is expected. It's not always clear how much of this configuration is actually done in hardware vs. a configuration routine in factory ROM running right after reset, with some apparent variation between models.

Finally, with regards to the semantics of your question, reset_handler() is a function and a label with meaning only to the C compiler and object file formats which retain symbols of some type. By the time the code gets into the chip, that is just a sequence of instructions at some memory location, and it stays at that location regardless if any effective or ineffective vector table entry is or is not pointing to it. The only way the actual code would move is if software on the chip moved it, or a hardware memory shadow mechanism configuration was changed (eg, shadowing either Flash or RAM to the start of memory).