In build bootloader

[atakancesim88]

Posted on January 26, 2016 at 10:54

Hi friends , 

I found following and did not understand why  __set_MSP(0x20002000) , why main stack pointer hold 0x20002000 ; why not 0x20000000 (sram start address) for stm32f429. 

When  I debug and look in 0x1FFF0000 , I saw 0x20002318?  Should I  use __set_MSP(0x20002318) ?  void jump_to_BootLoader(void) {     void (*SysMemBootJump)(void) = (void (*)(void)) (*((uint32_t *) 0x1FFF0004));     __set_PRIMASK(1);     RCC_DeInit();     SysTick->CTRL = 0;     SysTick->LOAD = 0;     SysTick->VAL = 0;     RCC_SYSCLKConfig(RCC_SYSCLKSource_HSI);     __set_MSP(0x20002000);     SysMemBootJump(); }

[Radosław]

Posted on January 26, 2016 at 12:23

This is correct

void (*SysMemBootJump)(void) = (void (*)(void)) (*((uint32_t *) 0x1FFF0004)); MSP is at adress 0x1FFF0000

[atakancesim88]

Posted on January 26, 2016 at 12:31

I see  , thank you :) , 

[Tesla DeLorean]

Posted on January 26, 2016 at 15:55

The stack descends, so at 0x20000000 you're going to immediate break things.

Yes you can use the default as described by the +0 vector, but code after that usually reconfigures it.Mapping the ROM at zero is likely more important.

[Radosław]

Posted on January 26, 2016 at 18:20

Bold

assumption. I never see reinitialization of MSP.  It's bad solution.

[Tesla DeLorean]

Posted on January 26, 2016 at 19:19

Yeah, and all the examples I've provided I load both SP and PC, because that's the smartest solution. We see a lot of other crap posted here. The broken stuff seems to spread a lot further.

What you do doesn't discount it being done other places, Keil's startup code usually moves to __initial_sp when it's done dealing with the statics. This allows the ROM/FLASH to unpack, buses and external devices brought up, and the full system be exploited. But there are plenty of examples where observed behaviour trumps assumptions, bold or otherwise.

Boot loader from STM32F103RET6
1FFFF000 20000200 dd $20000200 ; Stack
1FFFF004 1FFFF021 dd $1FFFF021 ; Start
1FFFF008 1FFFF745 dd $1FFFF745 ; NMI
1FFFF00C 1FFFF747 dd $1FFFF747 ; Hard
1FFFF010 SUB16 sub_1FFFF010:
1FFFF010 F8DF D004 ldr.w sp, [pc, #4] ; $1FFFF018=$20000200
1FFFF014 F000 FB9A bl sub_1FFFF74C_Main
1FFFF018 20000200 dd $20000200 ; Stack
1FFFF01C SUB16 sub_1FFFF01C_RunAt: ; Xref 1FFFF766
1FFFF01C 4700 bx r0
1FFFF01E 0000 lsls r0, r0, #0
1FFFF020 SUB16 sub_1FFFF020_Start:
1FFFF020 4800 ldr r0, [pc, #0] ; ($1FFFF024=$1FFFF011)
1FFFF022 4700 bx r0
1FFFF024 1FFFF011 dd $1FFFF011 ; sub_1FFFF010

I can be a troll if you want me too... I'm under a pretty large bridge.

[Radosław]

Posted on January 26, 2016 at 19:33

This is bootloader. And i treat this as exeption. Why?

When you remap memory. usualy we need to check if stack is in RAM and  reset handler is in FLASH or RAM range address.  Of corse aplikaction rum with remap can assume that someone forgot set property stack ponter and set it again for handling eventualy problems. But in normal situation  reinitiation of MSP is not good idea, like in this situation becose you can set msp to  region used for other purposes.  Jan code that you shows is bad example, in this same reason. will be more elegant to reinicjalize msp by adres from 0x1FFFF000, to prevent bad or missing initialization by aplication colling bootloader. Stack is managed by linker, when you reainitialize MSP with other value that is in adress mapped to 0, effects can be strange.  

[atakancesim88]

Posted on January 26, 2016 at 21:34

I am working on it for 4 hours and stilll unable to works it.

I am sending 0x7F with from pc and stmf100 returns differents values , Some times ı got 0x79. I dont use pull up resistors , Do ı have to or sould ı use pull up resistors.However , what you mean with Mapping the ROM at zero is likely more important? I dont understand what should I do ? Do I have to reset SYSCFG_MEMRMP bit?On the other hand AN2606 say that disavle all peripheral but it also say that enable USART1 , i dont understand that. When I enable USART1 then all peripheral is being not disabled? Should I ENABLE USART1 as always?

[Radosław]

Posted on January 26, 2016 at 22:10 Yes You must remap memory in SYSCFG by MEM_REMAP. You can't change  GPIO setting coresponding to UART1. The best way it to reset all periferals in RCC to state at power on reset.

[atakancesim88]

Posted on January 27, 2016 at 07:18

I can not found SYSCFG register in STM32F100 , you tought I am working on stm32f4 but ı am workin on stm32f100, 

How can I

Mapping the ROM at zero on stm32f100?