BootLoader from the RAM

[Barbie]

Posted on February 08, 2013 at 23:19

If I have a new DFU file I put on the RAM section and I want to upgrad the software with this file.

How I should configure BOOT0,BOOT1 in the boot mode time and after it on the next reset?How I point to the automatic boot to take the new DFU file from a specific location in the RAM area?ReagrdsBar. #boot-from-ram

[Tesla DeLorean]

Posted on February 09, 2013 at 16:32

BOOT0=1, BOOT1=1 Will run a suitably structured RAM image at reset.

To jump to some arbitrary image location in RAM you'd need to do so from a small flash based loader, as the hardware is only going to use 0x20000000 for a RAM base, which is shadowed at ZERO. The less contrived you can make this process the easier it will be to implement successfully.

[Barbie]

Posted on February 09, 2013 at 21:37 Thanks. So if I put the DFU image start on 0x20000000 and make BOOT0,1=1 it will boot from there and download the new SW ? Does it know also where it end by the DFU format? Reagrds Bar. 

[Tesla DeLorean]

Posted on February 10, 2013 at 01:15

Basically, but it might be complicated by a couple of factors.

STM32 RAM booting doing some odd things with the PC vector, STM32F1 parts jump to very specific locations, you'll have to double check. RAM may also be used by the System Loader/DFU code, you'll need to analyze exactly what regions of RAM are used, and if this compromises your goal. Again something you can address with a stub boot loader of some kind in FLASH. I'm not sure how the end of DFU image plays into your scheme, please explain. Where the compiled code defines it's code/data sections is a matter between you and the linker.

[meilinxiaoxue]

Posted on September 17, 2015 at 15:29

hi:

what dose ''STM32F1 parts jump to very specific locations'' mean?what is the ''specific location''? , I did a lot search  for ram booting ,however not much useful things;do you have some document about this booting mode? thx

[jpeacock]

Posted on September 17, 2015 at 16:27

The 'F1 always starts at the reset address in the vector table.  After a reset the vector table is located at 0x0000 0000.  The actual memory present at that location is set by the BOOT pins.  It can be the flash memory at 0x8000 0000, the embedded SRAM at 0x2000 0000, or the system bootstrap at 0x1FFF F000.  Those are the ''very specific'' addresses Clive mentions.

You can find this information in the F1 reference manual under Boot Configuration in the Memory and bus architecture section. Once the processor jumps to the reset vector you are operating within the selected memory region and are no longer in the 0x0000 0000 address area.   Jack Peacock

[jpeacock]

Posted on September 17, 2015 at 16:30

Oops, an extra F in the system memory base.  The internal boot starts at 0x1FFF 0000.

[Tesla DeLorean]

Posted on September 17, 2015 at 18:52

Actually, I'm referring to the fact is doesn't call the PC specified in the vector table as you expect, and in fact jumps somewhere else based on the specific part being used. I dug into this back perhaps in 2007, and there might be old forum stuff related to it. There was some conjecture that it was executing some other code first, but I've not dug into it that deeply.

Currently the behaviour is encapsulated in the GNU startup files for RAM, the BootRAM word is basically placed at a fixed address after the vector table, and is coded as an indirect jump to the real starting PC at [base + 4] so execution starts as expected. It consider booting from RAM a very narrow and specialized case.

...
.word USBWakeUp_IRQHandler
.word 0
.word 0
.word 0
.word 0
.word 0
.word 0
.word 0
.word BootRAM /* @0x This is for boot in RAM mode for
STM32F10x Medium Density devices. */
...

[meilinxiaoxue]

Posted on September 18, 2015 at 03:56thanks very much clive1,that is very useful info.thx again

[meilinxiaoxue]

Posted on September 18, 2015 at 04:01thank you peacock.jack.003, there has some unusual behavior when boot from ram.