Booting from RAM

[damh]

Posted on April 14, 2010 at 16:09

Booting from RAM

[Tesla DeLorean]

Posted on May 17, 2011 at 13:47

It's discussed in the TRM (RM0008, 13902) Section 2.4

This aliases the physical memory associated with each boot mode to Block 000 (boot memory). The values on the BOOT pins are latched on the 4th rising edge of SYSCLK after a Reset. It is up to the user to set the BOOT1 and BOOT0 pins after Reset to select the required boot mode. The BOOT pins are also re-sampled when exiting from Standby mode. Consequently they must be kept in the required Boot mode configuration in Standby mode. Even when aliased in the boot memory space, the related memory (Flash memory or SRAM) is still accessible at its original memory space. After this startup delay has elapsed, the CPU starts code execution from the boot memory, located at the bottom of the memory address space starting from 0x0000 0000. So When BOOT1 = BOOT0 = 1 it is supposed to map/shadow 0x20000000 to 0x00000000 and pull MSP=[0x00000000]; PC=[0x00000004] I can't get my board into that state easily, but the following HEX file should emit a brief message out of USART1 at 115200,8,N,1 -Clive :020000042000DA :10000000004400204501002061020020550200202C :100010005F02002025020020A7020020000000004F :100020000000000000000000000000007502002039 :10003000410200200000000065020020770200203D :10004000A902002063020020790200206B02002038 :1000500051020020670200204302002047020020D6 :10006000490200204B0200204D0200202B020020FC :100070002D0200202F020020310200203302002038 :10008000350200203702002021020020A3020020B8 :10009000A502002027020020290200204F02002094 :1000A0007B020020810200207F0200207D020020D0 :1000B00083020020850200208702002059020020D0 :1000C000570200205D0200205B0200206F0200202A :1000D000710200209B0200209D0200209F02002050 :1000E0004502002069020020A10200208F020020AA :1000F000950200209302002091020020230200209C :10010000530200206D0200208902002073020020AB :1001100097020020990200208B0200208D0200200F :10012000390200203B0200203D0200203F02002057 :10013000DFF80CD000F062F800480047C902002048 :100140000044002000F014F8264B00F041F8264847 :1001500000470A0D57656C636F6D65206F6E626FA7 :100160006172642066726F6D2052414D210A0D004C :100170001E4844F2040181611D481E4941601E4829 :1001800000218180452101815FF4C061018200214D :1001900001820021018342F20C0181814FF00A02A9 :1001A000D0F8001011F08001FAD04FF02301C0F810 :1001B0000410B2F10102F3D170470F4A00F0FF00C2 :1001C000D2F8001011F08001FAD0C2F80400704794 :1001D000187810F0FF0004D0FFF7EFFF03F10103E0 :1001E000F6E7704752010020310100200010024064 :1001F00000080140B444444400380140064C074D17 :1002000006E0E06840F0010394E8070098471034E6 :10021000AC42F6D3FFF790FFCC020020DC020020B6 :1002200070477047FEE770477047704770477047E8 :100230007047704770477047704770477047704706 :1002400070477047704770477047704770477047F6 :1002500070477047FEE77047704770477047FEE78A :1002600070477047704770477047704770477047D6 :1002700070477047704770477047704770477047C6 :1002800070477047704770477047704770477047B6 :1002900070477047704770477047704770477047A6 :1002A000704770477047FEE7704702E008C8121FAA :1002B00008C1002AFAD170477047002001E001C14F :1002C000121F002AFBD17047FEE70000DC0200206D :0C02D0000040002000040000BA020020E2 :0400000520000131A5 :00000001FF

[damh]

Posted on May 17, 2011 at 13:47

Ok, thanks, I tried it.

Booting from SRAM is buggy. The first 17 bytes are not remapped to addresses 0x00000000 to 0x00000011, the rest is correctly remapped from SRAM. If I boot from flash or internal flash the first 17 bytes are correctly remapped. My STM32F103VE always jumps at 0x200001E0 and sets MSP to 0x20005000.  Hardfault and NMI are tied to address 0x20000004. So I wrote a programm with the same entry values. Then the system runs.

[Tesla DeLorean]

Posted on May 17, 2011 at 13:47

That's kind of odd, is the debugger/loader using the front of RAM as scratch? The ''RAM for algorithm'' defaults to 0x20000000 for Keil/U-Link Cortex

My board doesn't permit boot to RAM so can't test it fully, need to dig up a dev board. As for reset, only R13, R14 and R15 have specific values, the others just contain random retained junk across the reset (ie preserved as last state). The boot vector defines R13/SP and R15/PC, the value 0xFFFFFFFF goes into R14/LR

[Tesla DeLorean]

Posted on May 17, 2011 at 13:47

Just to wake this up, there did/does appear to be a RAM booting issue.

The GCC build places 0xF108F85F at location 0x108 00000108 F85F F108        ldr.w    pc, [pc, #-264]    ; $000004=$08000D1D https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/DispForm.aspx?ID=6365 __attribute__ ((section(''.isr_vector''))) void (* const g_pfnVectors[])(void) = {   &_estack,            // The initial stack pointer   Reset_Handler,             // The reset handler   NMIException,   HardFaultException,   MemManageException,   BusFaultException,   UsageFaultException,   0, 0, 0, 0,            /* Reserved */   SVCHandler,   DebugMonitor,   0,                      /* Reserved */   PendSVC,   SysTickHandler, ...   USBWakeUp_IRQHandler,   0,   0,   0,   0,   0,   0,   0,   (void *)0xF108F85F //this is a workaround for boot in RAM mode. }; For high density the magic address is 0x1E0

+ (void *)0xF1E0F85F /* @0x1E0. This is for boot in RAM mode for

+ STM32F10x High Density devices. */ https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/DispForm.aspx?ID=7268 So apparently an issue, but not finding any really good cite from ST

[waclawek.jan]

Posted on October 23, 2017 at 21:36

Thanks Clive. Very interesting detail.

Jan

[Tesla DeLorean]

Posted on October 23, 2017 at 22:54

Perhaps ST can dig the cites out of the archive, I'm sure the original question had more content as well, but the two threads don't impart enough detail for me to figure out where they point. The Wayback Machine didn't provide anything useful.

[waclawek.jan]

Posted on October 24, 2017 at 01:35

I'd be more grateful if ST would document this properly, as they should have done initially.

I hate things being hidden into compiler m@gic.

JW