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).


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?

  • \$\begingroup\$ this has been asked and answered. VTOR resets. And if you do your software development right then there is no reason to muck with the vector table you simply point VTOR at it. Unless this is an RTOS and you are dynamically adding and removing interrupts (which you certainly dont do by changes to VTOR, you use VTOR one time to move to ram then you would update on the fly added/removed interrupts in ram, runtime). \$\endgroup\$
    – old_timer
    Jun 22, 2020 at 17:14
  • \$\begingroup\$ @old_timer can you share a link to that question you mention? \$\endgroup\$
    – muyustan
    Jun 22, 2020 at 17:21
  • \$\begingroup\$ its just quotes from the arm documentation that covers the topic of the reset and vtor. please provide a detailed question including disassemblies enough to show the vector table and addresses of functions in that table. plus what you want to do with it how you want to use vtor with detailed examples of the before and after. \$\endgroup\$
    – old_timer
    Jun 22, 2020 at 19:09
  • \$\begingroup\$ otherwise the arm documentation covers it. \$\endgroup\$
    – old_timer
    Jun 22, 2020 at 19:16

1 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).

  • \$\begingroup\$ so when I hit the reset button(the black one on the board), the first thing that happens is not Reset_Handler() then. MCU loses power, then restarts, VTOR returns to reset value 0x00000000, and only after then Reset_Handler() is executed. Correct? \$\endgroup\$
    – muyustan
    Jun 22, 2020 at 17:20
  • \$\begingroup\$ No, it has nothing to do with power, it is a reset of state, VTOR and most other special function registers, to the reset values as given in the documentation. \$\endgroup\$ Jun 22, 2020 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.