How to boot from SRAM on STM32L053

[Alexey Ostrejkovsky]

Posted on January 03, 2017 at 13:10

I have Nucleo-L053 with STM32L053 onboard. I want use SRAM for debug programs, not Flash (only 10000 rewrite-cycles :). But this MCU has only 1 pin 'Boot0'. How I can boot load to SRAM and then boot from here?

I red in Reference Manual table 11: there are Boot1 and Boot0.

Ok, Boot0 is a pin. What is the Boot1? How I can switch it?

#stm32l053

[Khouloud GARSI]

Posted on January 03, 2017 at 13:48

Hi Alexey,

Below is the ''Boot modes'' table(extracted from the reference manual)

As you may see, the BOOT1 value is the opposite of the nBOOT1 option bit.

If this answers your request, please click on correct 

:)

Khouloud.

[Alexey Ostrejkovsky]

Posted on January 03, 2017 at 20:38

Many thanks for Your answer.

Ok, I have seen it in Manual. But I didn't understand, how I can switch nBOOT1 option bit. Were is this bit? How I can to reach this bit? May be, in programmer (debugger) software? Of course, I must use setting of this bit before programming of STM32. In other case the code of the program does not fall into the right place!

I use ST-Link v.2.1 under Eclipse Luna from AC6. How can I manage this bit?

[Tesla DeLorean]

Posted on January 03, 2017 at 21:03

Pretty sure it is possible to get a debugger to download and run from RAM without doing anything with the BOOTx settings. You'd set the target memory regions from ROM and RAM to fall into the SRAM space you've divided down via the linker script, and use a debugger script to download and configure the SYSCFG memory mappings. This can be done straight forwardly with Keil, I'd suspect similar techniques are applicable to GNU/GDB.

[aaron239955_stm1_st]

Posted on January 04, 2017 at 04:06

you've lost a zero in your write cycle limit.  It is at least 100,000 not 10,000.  Unless you are reloading programs 1,000 times a day you should not have an issue requiring you to avoid the FLASH for program storage.

[Jeroen3]

Posted on January 04, 2017 at 12:47

Those are specified numbers. They can probably take more.

I've never worn out a demoboard. It does get slower over time, but it will still work.

Data retention would be less though.

[Tesla DeLorean]

Posted on January 04, 2017 at 17:37

I think we had the discussion about the L053 type part the other week, definitely specifies FLASH endurance of 10K min

http://www.st.com/content/ccc/resource/technical/document/datasheet/8a/f4/9d/d7/61/1b/46/b4/DM00105960.pdf/files/DM00105960.pdf/jcr:content/translations/en.DM00105960.pdf

 

I suspect the life in the ambient room temperature of a development lab to be much higher. If you come close to doing that  number of cycles during programming you should perhaps reconsider your coding/testing methodology, and buy a handful of $10 boards.

[Bogdan Golab_2]

Posted on May 20, 2017 at 20:09

I've been running programs in SRAM for years on all STM32 MCU using Keil debugger. The procedure is common for M0+ and better ARM Cores (only M0 is slightly different). In this case of L0 MCU (M0+ core):

After selecting the MCU (or generating the project skeleton using CubeMx)

-set the RO area in SRAm region (just divide the available IRAM size and set offset for IROM) e.g.: Target->IROM:0x20000000/0x1A00, IRAM1: 0x20001A00/0x600

- a few usefull settings, particulary VECT_TAB_SRAM: C/C++->Define:STM32L053xx,USE_STM32L0XX_NUCLEO,USE_HAL_DRIVER,VECT_TAB_SRAM-Linker->check 'Use Memory Layout from Target Dialog'-Debug->Use 'ST-Link Debugger', Initialization File: Dbg_RAM.ini, Load Application at Startup, Run to main(), -Debug->Setting->Reset:'Autodetect', Port:SW/1MHz-Utilities->uncheck 'Update Target before Debugging'-Build Target(F7)-Start/Stop Debug Session: Ctrl-F5

After starting the debugging the code is loaded to SRAM a a result of the Dbg_RAM.ini.

The procedure is almost the same for any STM32 MCU better than M0 (F0 series). In this case we cannot relocate the VTOR but you can re-map memory using  SYSCFG.

This of course is useful as long as you can fir the code and data into the SRAM space available on particular MCU. In case of L0 you are limited to 8kB. It's not a problem if you do not use HAL library;)

[A K]

Posted on November 29, 2017 at 18:08

Hi Alexey,

back to your original question on how to set BOOT1 - this might be useful for other devs as well, since the doc is somewhat ambiguous.

(1) In principle, all you have to do is write to the option bytes at 0x1FF80000 and 0x1FF8004 with the values 0xFF5500AA and 0xFF8F0070, respectively.  Here, the complementary bits 31-16 of bits 15-0 are already been taken care of.

(2) For security reasons, the options bytes are locked by default.  To that end, first unlock FLASH_PECR register (clearing its PELOCK bit) by writing 0x89ABCDEF followed by 0x02030405 to FLASH_PEKEYR.  Now you are allowed to clear the OPTLOCK in FLASH_PECR by writing values 0xFBEAD9C8 and 0x24252627 to FLASH_OPTKEYR.

Finally, you have write access to OPTIONBYTE1 and OPTIONBYTE2 to perform the task explained in (1).  It is recommended to execute this routine from RAM.

You may verify your work by reading FLASH_OPTR, it should change from reset value 0x807000AA to 0x007000AA.  There, nBoot1 = 0!

As I was studying the STM32L053's RM I figured that bits OPTLOCK, PRGLOCK, and PELOCK in FLASH_PECR are not documented correctly.  For each it should rather state:

0: The write and erase operations in the Option bytes area are enabled.

1: The write and erase operations in the Option bytes area are disabled.

Edited: 'you' -> 'it'