Booting from RAM

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

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

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.

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