STM32F103: SRAM startup

[Nick Belazor]

Posted on May 26, 2018 at 01:18

Hi all!

When i try startup my firmware from SRAM on stm32f103RE then nothing.. 

BOOT1 and BOOT0 is set to 1

Firmware developed on KEIL. Please, look my project settings:

int main(void){

__disable_irq ();

SCB->VTOR = 0x20000000U;  __set_MSP(*((volatile uint32_t *) 0x20000000U)); __DSB (); __enable_irq(); 

.....

init's and etc and main programm 

...... 

}

1. I place my compiled firmware over ST-Link Utility on region 0x20000000 (upload dump and check it, all ok),

2. set BOOT1 & BOOT0 = 1,

3. and press RESET. Nothing! =(  programm does not work (not blinked).. does not startup

why?

thank

#startup #sram #boot

[Tesla DeLorean]

Posted on May 26, 2018 at 02:56

As discussed in other threads, over several years, the F1 has some special requirements with the placement of the Reset_Handler code. You will see 'BootRAM' in the GNU/GCC startup.s files for a given low, medium or high density parts. This is effectively a LDR PC,[0x20000004] instruction, but could just be your handler code.

https://community.st.com/community/stm32-community/blog/2018/05/13/boot-from-embedded-sram-mechanism-in-stm32?commentID=6232#comment-6232

 

Your main() function really doesn't have to do any of that. SCB->VTOR will be zero at reset, if SRAM is mapped at zero (and you can't change it on the F1, everything will be fine). Usually SCB->VTOR is set in SystemInit()

[Nick Belazor]

Posted on May 26, 2018 at 09:51

Hi, Clive 

thank you for your reply! But i don't understand what to do..

can you more fully explain?

what am I doing wrong in my situation?

[Nick Belazor]

Posted on May 26, 2018 at 10:04

and

when i startup code over Debug (st-link v2) mechanism - all work fine.

programm correct work and trace

i use INI-file:

/*----------------------------------------------------------------------------

Setup() configure PC & SP for RAM Debug *----------------------------------------------------------------------------*/FUNC void Setup (void) { SP = _RDWORD(0x20000000); // Setup Stack Pointer PC = _RDWORD(0x20000004); // Setup Program Counter _WDWORD(0xE000ED08, 0x20000000); // Setup Vector Table Offset Register}

FUNC void OnResetExec (void) { // executes upon software RESET

Setup(); // Setup for Running}

load %L incremental

Setup(); // Setup for Running

*----------------------------------------------------------------------------*/

what is incorrect when programm startup from hardware boot(BOOT0 & BOOT1 == 1)? 

[Tesla DeLorean]

Posted on May 26, 2018 at 13:17

>>all work fine

No doubt, the debugger completely changes the dynamics, you are fighting specific conditions in the hardware that occur in a real reset.

[Tesla DeLorean · Accepted solution]

Posted on May 26, 2018 at 13:33

If the part expects Reset_Handler to be at 0x200001E0 then it is not going to work if your build puts it at 0x20001234 or 0x2000120

Place ' DCD 0xF1E0F85F' at the end of the Vector table space, so it falls at 0x200001E0, to permit operation in this mode.

Look at STM32Cube_FW_F1_V1.6.1\Drivers\CMSIS\Device\ST\STM32F1xx\Source\Templates\gcc\startup_stm32f103xe.s

Attached (use Thread View) is a startup_stm32f103xe.s for Keil modified to permit RAM Booting

________________ Attachments : startup_stm32f103xe.s : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxYb&d=%2Fa%2F0X0000000azq%2FyPX56Ftsj8dol.KvB31qfnssUB1rqIJjdzYH2U761rQ&asPdf=false

[Nick Belazor]

Posted on May 26, 2018 at 21:50

Cool!! it is worked!! 

but i place 

DCD 0xF1E0F85F with lead zeroes for align end of vector table in my startup

thank you, Clive for it magic