Boot from SRAM

l yk · ‎2017-10-23

Posted on October 23, 2017 at 10:49

I have a question about the stm32f103xx. I want to know how it boots from Embeded SRAM. I have known that the IBUS of Cortex-M3 can't access the SRAM from the reference manual. When boots from the SRAM, how Cortex-M3 fetches instructions from SRAM?

l yk · ‎2017-10-24

Posted on October 24, 2017 at 13:48

Thanks for your sharing!

But it does not solve my problem. Do you know which bus the CPU gets the MSP value and reset handler through when booting from embedded SRAM? And why?

Uwe Bonnes · ‎2017-10-24

Posted on October 24, 2017 at 14:25

rm0008 is quite clear:

Due to its fixed memory map, the code area starts from address 0x0000 0000 (accessed

hrough the ICode/DCode buses) while the data area (SRAM) starts from address

0x2000 0000 (accessed through the system bus). The Cortex®-M3 CPU always fetches the

reset vector on the ICode bus, which implies to have the boot space available only in the

code area (typically, Flash memory). STM32F10xxx microcontrollers implement a special

mechanism to be able to boot also from SRAM and not only from main Flash memory and

System memory.

Probably boot from sram maps some system code at 0x0 that fetches stack from 0x2000000 and start address from 0x20000004. I don't have a F1 at hand to test...

waclawek.jan · ‎2017-10-24

Posted on October 24, 2017 at 14:34

rm0008 is quite clear:

No, it's not clear at all. Clear, in my opinion, means thoroughly documented. There's no mention of the m@gic addresses there, nor the fact that the table should start at 0x20000000 in SRAM.

Probably boot from sram maps some system code at 0x0 that fetches stack from 0x2000000 and start address from 0x20000004. I don't have a F1 at hand to test...

Probably not. IMO, in light of what Clive wrote above, what happens is that while the processor always fetches stack and start address from FLASH from 0x00000000/0x00000004, when the boot pins are set to boot from SRAM it causes an interrupt which jumps to the 'm@gic address' in the upper area, where there is some code which performs the fake reset from SRAM.

I don't have/use and I don't even want to have/use a 'F1 - I am just curious.

JW

Tesla DeLorean · ‎2017-10-24

Posted on October 24, 2017 at 15:29

Most likely there is a small ROM or combinational logic on the I-BUS that feeds 0x20005000/0x20000109 for SP/PC when the BOOTx pins select SRAM mapping.

The SRAM does map into the zero space, and the processor is capable of executing code from SRAM, so there might be other additional plumbing as necessary. It is not something that I have dwelt on as it appears to function in a manner that supports what I want.

VTOR can be set to 0x20000000 and it fetchs vectors in normal operation.

Like Jan I'm not hugely invested in the whys/wherefore here, and I'm not attempting to clone the part.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

damh · ‎2017-10-27

Posted on October 27, 2017 at 15:02

At 0x00000000 is a small ROM/Flash (16 bytes) mapped with data:

00 50 00 20 E1 01 00 20 04 00 00 20 04 00 00 20 (F103ZET6)

or in ints 0x20005000, 0x200001E1, 0x20000004, 0x20000004

You can read out the area by yourself. Any read behind 0x0F will force a hard fault and jump to 0x20000004.

It is NOT a real reset (i.e. VTOR not set). It's the same FAKE-reset as a reset to flash bank 2 (newer and bigger versions of F1).

What do you want to do?

I think (cannot prove) BOOT1 is a fake-BOOT-pin. BOOT0 starts main flash (0) or system flash (1). Boot from SRAM and flash bank 2 is a 'virtual' reset, done probably by system memory.