Booting STM32 from SRAM.

[marcus2399]

Posted on March 11, 2009 at 19:55

Booting STM32 from SRAM.

[raptorhal]

Posted on May 17, 2011 at 13:04

🙂 Your SRAM will stay up if you keep it on battery power or suitable alternate power to pin Vbat.

[marcus2399]

Posted on May 17, 2011 at 13:04

Hello!

I developed a small application running on my STM32-P103 board from Olimex. I would like to boot it from SRAM, to avoid over-usage of the embedded flash. It is easy to configure the board using jumpers to boot from SRAM, but that means that when powering up the board it immediately starts executing garbage at 0x20000000 (start of SRAM). It will do bad things and end up in handler mode looping around in the exception vectors I happen to have at 0x0. Next thing I do is stop the board using OpenOCD and download my application to SRAM. After that i jump to my boot routine in SRAM which sets up the NVIC vector table offset register, inits BSS and then starts the main application. I would like to have the CPU in reset state when jumping to the boot routine, i.e. privileged thread mode. Right now the CPU is in random state depending on exactly when I stop it after power on from the random SRAM state. What is the proper way to do this? Should I stop the CPU, load the code to SRAM and then writing the NVIC vector table offset register and then reset the CPU using OpenOCD? Does that work? If so, my exception table would cause a jump to the boot routine and everything would be fine. Best regards, Marcus

[marcus2399]

Posted on May 17, 2011 at 13:04

Is that really necessary? The board is continously powered, so does the reset signal cause the SRAM to lose it's contents?

[alex_ribe]

Posted on May 17, 2011 at 13:04

Hi:

What would be the problem of using the Flash Memory? The parts have endurance of 10000 erase/write cycles. You can debug from RAM (if that is what you need to do) as well, by placing your code in RAM and executing from RAM. The compiler, linker should take of that (if you correctly set them up). What is that you want to accomplish? Regards, Alex

[marcus2399]

Posted on May 17, 2011 at 13:04

What I want to accomplish is two things:

First, I feel more comfortable by just easily loading to RAM from gdb, everytime I have recompiled, then reseting the target (probably from the openocd prompt). My own vectors (in RAM) would then be used to jump to my own boot routine and start the application. Having many breakpoints also requires you to run from RAM. Second, I'd really like to know if this works - can I reset the STM32 and have it boot from RAM if I write the proper value to the NVIC vector table offset register, before trigging a reset? As I'm writing this I realize that as the reset value of the VTOR is zero, writing the register before doing a reset is probably completely usesless, am I right? In that case, is there not ANY way to have a boot routine in RAM called in privileged thread mode without starting of from a vector in flash at 0x0? If not, I could just as well boot from flash, to rid myself of all hazzle... Best regards, Marcus

[andreas2]

Posted on May 17, 2011 at 13:04

You do not need to go through all this trouble, the boot selection does it for you. The core always fetches the reset vector from address 0x0, because of the VTOR reset value. However, depending on the boot pin configuration, either internal flash (0x08000000), internal sram (0x20000000) or system memory (0x1ffff000) is aliased at address 0x0. So simply halt your CPU, upload code to sram, and issue a reset. The VTOR can optionally be setup to point to the non-aliased address (0x20000000) once your application is up and running.

The contents of the SRAM will outlive a reset, as long as Vdd is powered. It will NOT be retained on Vbat power, as raptorhal said, only the RTC and backup registers will. The following gdb commands should do the trick, 'monitor' passes the command to openocd. monitor reset load monitor reset thb main c Alternatively, 'monitor soft_reset_halt' is a faster way of doing a reset, but I'm not sure it will always work independently of state. It should work for the second invocation though.

[marcus2399]

Posted on May 17, 2011 at 13:04

I am a little confused regarding the aliasing at 0x0. Originally, I assumed that it would work just like you say (i.e. SRAM could be aliased at 0x0), but according to ST:s ref manual RM0008, chapter 2.4 (boot configuration):

''Boot from the embedded SRAM: SRAM is accessible only at address 0x2000 0000.'' That is also how it seems to work... I really wonder why, because it seems not very practical. Thanks for your advice regarding the GDB ''monitor'' command! Best regards, Marcus

[andreas2]

Posted on May 17, 2011 at 13:04

Indeed, the have changed that text since rev 6 which I have read. But now it also mentions that ST has made workarounds to be able to boot from SRAM, possibly by modifying the core's start-up behavior. From what the manual says, it should still work as I said, with the exception that it is not optional to set VTOR when running from SRAM.

Hm, I wonder if this workaround has anything to do with the magic number that is placed a bit after the end of the interrupt vectors in the GCC startup code: ... RTCAlarm_IRQHandler, /* RTC Alarm through EXTI Line */ USBWakeUp_IRQHandler, /* USB Wakeup from suspend */ 0,0,0,0,0,0,0, (void *)0xF108F85F /* @0x108. This is for boot in RAM mode for STM32F10x Medium Density devices. */ I asked about this here once before, but I don't remember if I ever got an answer...