Ways to speed up writing to program flash

[shotaro]

Posted on November 20, 2012 at 23:33

MCU is an STM32L MD part.

My application calls for optical-based software updates (don't ask if I can change it), and I'm at the process of writing that part of the software. I've been benchmarking how long it takes and for downloading and programming 60KB, it's taking about a minute and 10 seconds. This seems really long for some reason. I'm not using the peripheral library function calls for this (I was hoping putting the function in memory would help), and I tried the ramfunc version but the processor goes into lala-land after a few data packets are sent to it. My write operation is this: for(i = 0; i < 32; i++) {   *(__IO uint32_t *)Address = Data[i];   Address += 4;   status = FLASH->SR;   /* Spin until operation is done. */   while((status & 0x00001F0F) != 0x0000000E)   {     status = FLASH->SR;   }   /* Break on errors */   if((status & 0x00001F00) != 0)   {     break;   } } EDIT: I'm going to see if it's my PC app that I'm using the squirt the data over as well. I should mention that the PC app will not send data until the target has written the previous data and says it's okay to send the next one.

[charlieincanada69]

Posted on January 11, 2013 at 19:50

OK thanks Clive that sounds good. I'll write my own routine for pushing blocks of data to the flash. The ST library only seems to give functions for word/half word operations.

I'm on IAR 6.4 at the moment. In your opinion what is the easiest way to get the firmware writing routine running in RAM whilst leaving the rest in flash? This would have to work from the application rather than just on initial programming as it would have to survive the remote update process (i.e. either alpha or beta app could be running).

[M0NKA]

Posted on January 11, 2013 at 20:37

Hi,

Yeah, as already pointed out - you should always have the write routine in RAM. Regards, Chris

[Tesla DeLorean]

Posted on January 15, 2013 at 21:58

I tend to write such functions in assembler to control/prevent leakage to external routines/libraries. This also allows for self-relative code, ie address independent.

You can carve out space in RAM for them to be placed, or copy them to a stack allocation. Other tricks to speed things up are to blank check flash pages/sectors prior to erasing them, and not erasing ones already blank. Not attempting to write 0xFFFF/0xFFFFFFFF to blank cells.

[charlieincanada69]

Posted on January 15, 2013 at 23:14

Thanks Clive. Using the help you gave my in [DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Running%20a%20particular%20function%20from%20RAM&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B]the other thread all of the write functions (my own this time rather than the ST library) are running from RAM.

There are no compile or linker errors and even the debugger seems happy enough. However... although the process still works perfectly it is still really slow. I have also disabled interrupts for the FLASH write function as recommended in the

http://supp.iar.com/FilesPublic/UPDINFO/004916/arm/doc/EWARM_DevelopmentGuide.ENU.pdf

. Pseudo code is: receive update command call generic (abstracted) firmware write function disable interrupts call firmware write function in RAM ...flash is written here ... enable interrupts return result Am I missing anything obvious?