Electronic – STM32 not booting without J-link

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.

My bet is on boot0; Check that you've got it pulled low.

The boot0 pin selects where the MCU will start executing code from when it boots up, ie. comes out of reset. If boot0 is low, it'll execute your code from flash, but if it's high, it'll execute the internal bootloader from the system memory.

My guess is that you have left boot0 floating, and when you're doing a cold boot (ie. disconnecting and reconnecting power), it'll be close to zero, so the MCU will boot your code from flash, but when you do a warm boot with the reset signal, the pin will have floated to a higher value, is read as high, and the MCU will boot to the internal bootloader from system memory instead of your code.

This explanation assumes you haven't touched the boot-related option bytes, which would change the behaviour. Also, in case you'll be working with different STM32 MCUs at some point, please note that they can have slightly different behaviour. Some have different boot-related option bytes. All I've seen so far have had a boot0 pin which behaves identically, but some also have a boot1 pin (which might be shared with a gpio pin) that you might also have to set correctly. In the MCUs I remember seeing, though, boot1 is only relevant if you want to be able to boot from system memory or SRAM.