Electronic – STM32F4 boot concepts and vector table relocation

cortex-mstm32f4

There are some things I don't understand on the boot process of the STM32F4 microcontroller.

My understanding is as follows:

  1. The ARM Cortex-M4 boots expects the stack pointer initialization value and the interrupt vectors on 0x00000000 + SCB->VTOR, whereas SCB->VTOR is cleared at reset.
  2. There is no memory at that location. Flash memory starts at 0x08000000, SRAM at 0x20000000.
  3. In order to make booting possible, the µC can map the flash or SRAM memory range to 0x00000000. The memory range to be mapped is defined by the state of the boot pins.

My questions:

  1. Why is the STM32F4 reference manual saying on page 69 that

    When the device boots from SRAM, in the application initialization code, you have to
    relocate the vector table in SRAM using the NVIC exception table and the offset register.

    ? In my point of view this is not necessary, as the whole memory region is aliased anyway. Interestingly this doesn't seem to be required when the flash region is remapped to 0x0 space.

  2. The only use for booting from SRAM I can think if is to reduce write cycles on the flash during development. Before you release the µC from reset, you write the program to SRAM using the debugger and then boot from there. However, as you have debugger access, there wouldn't be any restrains on where to boot from anyway. So why having this feature?

    That the boot position is derived from pins indicates (at least in my oppinion) that this feature is to be used not during development but in final operation. And in final operation, SRAM is clear at boot time. Hence it doesn't make sense to boot from SRAM.

Best Answer

Question 1:

I can't definitely answer your first question. But in the programming manual where the VTOR register is described (page 212) it states that bit 29 is used to determine where the vector table is located, either in the code region (0) or in the SRAM region (1).

Now I don't understand why this has to be done for the same reason you state, the SRAM gets aliased to 0x0, so why is there a need to set this offset?

The only guess I have is stated on your cited page 69. They say:

the code area starts from address 0x0000 0000 (accessed through the ICode/DCode buses)

the data area (SRAM) starts from address 0x2000 0000 (accessed through the system bus)

The Cortex ® -M4 with FPU CPU always fetches the reset vector on the ICode bus

Maybe on an interrupt the ICode bus is used, which cannot access the SRAM even when remapped (I don't know if this is true). This would explain why this bit has to be set accordingly, telling the core to use the system bus and access the SRAM.

Question 2:

While it might be true, that the SRAM is empty on the first boot of the device, it isn't necessarily for later boots. So you could create something like a battery powered device which gets its SRAM programmed during production and then runs until the battery is dead, which would clear its SRAM. I guess this would make reverse engineering the device a bit harder.

In a battery powered device you would probably use the standby mode to conserve power, and if you leave that mode, the Boot-pins are sampled again, so they must have the correct setting to get to the SRAM again.

You can also reboot the device safely as the content of the SRAM doesn't get destroyed if there is no power outtake.

Not a very convincing application to rectify all the trouble to remap the SRAM.

Related Topic