2016-08-19 01:11 PM
usart bootloader data section
2016-08-19 01:20 PM
2016-08-19 01:23 PM
The forum does not support mobile devices well, Android is workable with FireFox.
2016-08-19 11:20 PM
clive1, I realized that iOS was not at all compatible with the forum. Sorry for posting garbage.
What I was trying to post originally was:I am programming an STM32F0 device from an STM32F429 DISCO board using the USART systemmemory boot mode. I have generated a binary file in TrueStudio, read the file into the device onthe DISCO board and then transferred it byte by byte to the STM32F0 over the USART. When writing into the memory of the STM32F0 I start at its address 0x08000000, which I understandis the start address of the flash. It seems to work well and the STM32F0 seems to be up andrunning after the programming, but when looing into the linker file I realize that the .datasection is linked into RAM and not the flash. I understand that .data contains initialized dataand now I cannot understand how I possibly should have managed to get that section intoits right place when programming over the USART.Do I need to do something special for the .data section when using the USART system memory boot, or am I misunderstanding something here?Thanks!/M2016-08-20 05:18 AM
While the linker allocates/manages resources in RAM, this usually gets tacked on the end of the FLASH image in embedded so that the startup portion of the code can copy this down into RAM, or zero out sections, before it starts running your code. In GNU this is situated in the startup_stm32fxx.s file immediately after the Reset_Handler symbol, in Keil by calling __main, and IAR _cstartup
You should probably look at the .HEX file to see what addresses the linker output is covering. The scatter file or linker script should describe how the load regions are managed, ie RAM content nested inside FLASH. The boot loader can write data into FLASH or RAM2016-08-21 11:46 PM
I see clive1, thanks for the answer.
/M