Howto copy a section of my application into SRAM for In Application Programming using gcc ?

[mike-davies]

Posted on July 25, 2012 at 13:52

Hi,

I am developing an application for the STM32L151QC device using gcc and my application needs the facility to perform In-Application Programming.  The application update will be contained in an external hardware module which is connected via a UART.  Software for controlling the module and for retreiving files from it will exist in my application.  Obviously I want to reuse this software as well as existing interrupt routines for using the UART etc.

I have read the application note AN3310 ''Updating firmware in STM32L1xx microcontrollers through in-application programming using the USART'' and this seems to use ''#define __RAM_FUNC FLASH_Status __attribute__((section(''.data'')))'' from the peripheral library to generate a macro which places functions etc in SRAM. 

However I would prefer not to use up my SRAM space with functions when not required so would rather have all the relevant functions reside in flash when not in In Application Programming mode.  So ideally I would like a way to generate a coherent subsystem which normally lives in flash but which can be copied into SRAM when required and run from there.

So can anyone tell me how to use the gcc toolset to ensure a disparate selection of functions are contiguous in Flash and then find start and end of the area of flash containing them so as to be able to dma the code from flash into SRAM ?

I have found references for remapping the SRAM after copying it, but as I say, I have no requirement to boot from SRAM, only to execute from it.

Thanks,

Mike

[Tesla DeLorean]

Posted on July 25, 2012 at 14:03

Create a different section, direct the code to that, place that segment in the linker script, directing the data to flash, and with beginning and end markers.

Copy this data into a free area of RAM, dereference the offset of the routine you want to call, and call it. ie get the address the linker placed it at, subtract the base of flash, then add back the address base you used for the copy to RAM. Personally I find doing this in C is a mistake, as it's very hard to control what the code calls, or if it expects external library code which is hard to coral into the contiguous block. Make sure you generate address insensitive code, and not use hard addresses for things.

[mike-davies]

Posted on July 25, 2012 at 15:52

Thanks for your reply.

That does sound quite complicated, do you have a reference for the underlying steps involved in that ?  As an alternative is there any way I can use the ST-provided System memory bootloader without the BOOTx pins being set ?  If I could just jump into the System bootloader then that would save me a lot of effort but I cannot have user-accessible buttons or  jumpers on my device and there seems to be no way to set the boot space to the System memory without setting the BOOTX pins, unless you know another way ? Thanks again, Mike

[Tesla DeLorean]

Posted on July 25, 2012 at 19:06

I'm not sure it's complicated, it just requires an understanding of how micro-controllers work, how linkers and toolchains behave, the same methods have worked for years from 68K to MIPS and ARM.

You can definitely call into the System Loader, although it's expecting near reset conditions and no interrupts, PLL's and such. I'd normally generate a reset, catch a RAM based signature and jump to the System Loader from my reset handler. I've posted several similar solutions on the forum before. This one's on point, but there are probably others, pity the search here ***** so bad, dug this back up via Google, see also thread it's attached too.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/DispForm.aspx?ID=7024&RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32 Internal Bootloader

[mike-davies]

Posted on July 26, 2012 at 09:10

Thanks for your reply. 

Can you tell me whether ST have published the source code for the system loader and if so where I can find it ? Thanks again, Mike

[Tesla DeLorean]

Posted on July 26, 2012 at 13:17

No, but the protocol is well documented.

I did create an annotated listing for one of the F103 releases, and did some partial analysis of some others.  sourcer32@gmail.com

[David Littell]

Posted on July 29, 2012 at 20:16

Hi Mike,

You could add some external hardware to drive NRST and the BOOTx pins when triggered by a GPIO.  Your code would tap that GPIO when it wanted the system to come back up into the Bootloader.  Of course, the hardware would have to handle assertion/negation timing and coordination with other sources of NRST, BOOT1, and BOOT2.Dave

[mcuisp2]

Posted on August 06, 2012 at 07:01

You don't need run code in SRAM when IAP, for most STM32 chips.

[mike-davies]

Posted on August 06, 2012 at 09:49

You don't need run code in SRAM when IAP, for most STM32 chips.

Is that true ? STM's manual PM0062 ''STM32L151xx, STM32L152xx and STM32L162xx Flash and EEPROM programming'' available as CD00242299.pdf says on Page 20 that ''Half Page Write is possible only from SRAM, from external memory or from bank 1 to bank 2 and vice versa.''  I took that to mean that it is not possible to program the Flash except from SRAM unless the device supported multiple banks of Flash ? In any case I will need to clear and program the bulk of the Flash and it will be nearly as easy to copy the Flash updater into SRAM as it is to ensure that it lives in a specific part of Flash which I avoid erasing. Thanks for your reply, Mike

[mcuisp2]

Posted on August 06, 2012 at 12:16Yes, Some chips need run IAP code in SRAM, include your stm32l.But, Most STM32 don't need, stm32f1xx, etc.Sorry, I didn't read your topic clearly.