The problem of remapping of interrupt vectors table for STM32

1  why the interrupt vector table should be remapped.                COREM3 authoritative guide "However, for dynamic redistribution interrupts, CM3 allows vector table relocation-
-Start locating the exception vectors from other addresses.    the area corresponding to these addresses can be a code area, but it can also be a RAM area. The entry address of the vector can be modified in the Ram area. ”。             Puzzle:                                       1. If you do not remap, the address of the interrupt vector table should be this: 0X0000 0000 is SP
; 0X0000 0004 is the reset vector; 0X0000 0008 is NMI, followed by 4 increments in order of the interrupt number.           In this case, the interrupt vector table cannot be saved. Anyway, there are some function pointers, not much space, why do we have to re-map to other places??                                      2. If remapped, the entry address of the interrupt vector table becomes 0x0800 0000. But the part of the space that was opened at the beginning (0x0000 0000 ...) The interrupt vector table stored is not equal to useless.                                       Question one: to explain your doubts, first understand a few things. 1, regardless of whether the vector table has been remapped,

Both the SP and the reset entry are obtained from the 0-address vector table after the reset. The interrupt vector table at address 2, 0, is usually the ROM address.

Usually only by specifying a link address and then burning the rewrite. 3, in some products with upgrade features, usually divided into the boot and the app two parts.
Boot is usually not changed after the production, using the 0 address vector table, must be through a tool such as JTAG to be rewritten.

   boot with download function (USB, serial or SPI), users can download the app as needed. 4, note 2nd, the app usually needs its own design interruption service.
If you do not remap, only the boot design of the table program, through the boot jump, not high efficiency.    Erase 0 Address vectors, and boot will not boot if power is lost during the upgrade process.

Therefore, you need to go into the app and remap the vector table. Question two: Your understanding is right. However, the interrupt Vector table area at 0 addresses typically does not place code. Chip in the flash address allocation, there is very little flash address in a tight row after the vector table. Therefore, it does not affect.