cancel
Showing results for 
Search instead for 
Did you mean: 

Ways to speed up writing to program flash

shotaro
Associate II
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.
13 REPLIES 13
shotaro
Associate II
Posted on November 21, 2012 at 19:13

Maybe solving my own problems is good, but bleh.

My software had system tick running. I had good reason to believe because I have a event framework that uses systick to update timers, the MCU would freak out if it had to service something. So I just turned off interrupts for the duration of the function.
Andrew Neil
Chief II
Posted on November 22, 2012 at 07:27

''optical-based software updates''

 

Sounds fascinating! What do you mean by that?
charlieincanada69
Associate II
Posted on January 09, 2013 at 14:46

I am also experiencing slow write speeds to flash during my remote firmware update procedure.

Can you give any indication of the performance improvement you gained from turning off interrupts during the write function?

Thanks!

charlieincanada69
Associate II
Posted on January 09, 2013 at 17:33

OK I have tried disabling the interrupts but the write speed is painfully slow!

Any ideas on how to speed this up? I am currently using the library functions to write 16bits at a time.

jpeacock2399
Associate II
Posted on January 10, 2013 at 15:55

It takes up to 40ms worst case to erase a 1KB sector, so the erase time for 60KB would be 2.4 seconds.  A 16-bit update takes up to 70usec worst case, so 30K x 70usec would be in the 2.3 sec range.

Sounds like the problem is in the downloader, not the flash.

  Jack Peacock

charlieincanada69
Associate II
Posted on January 10, 2013 at 18:04

Thanks for the reply Jack. I'll check through my process and look for unspecified delays.

The update code uses an existing command struture/routine that can transfer data at around 256kbps. The only difference is that I am calling the write to flash routine. I'm using the ST library function

FLASH_ProgramHalfWord

to do the writing. Looking through the code I wonder if it is getting delayed in the 

FLASH_WaitForLastOperation

call...

Any other ideas/tips are welcome!

M0NKA
Senior
Posted on January 11, 2013 at 09:46

Hi,

The first thing i would check is the resulting assembler code and see if the flash write

func is really in RAM. Do you copy the function manually from flash to ram and then

call via absolute address, or you expect the compiler to do this automatically ?

BR

charlieincanada69
Associate II
Posted on January 11, 2013 at 17:58

Hi BR,

The device/firmware combination for this project allows the product to divide the flash into a bootloader plus 2 application spaces (alpha & beta). Whilst running in alpha, the beta flash can be overwritten with a new application. The bootloader is then configured to boot from the beta location. The same goes for the other way round. The application that is currently running can not be overwritten.

I have not attempted to put the flash write routine into RAM at all... Now you have suggested this it sounds like I should be doing that! My code is executed from flash rather than being copied to RAM. Could this be the reason for the slow write speeds? Because I am having to read from the flash to get the instructions to write to it?

I guess I should have thought of that before... 😉

Posted on January 11, 2013 at 19:29

The processor will stall when trying to read/execute out of flash while writing/erasing other portions. There is only one bank, so there is no independent operation.

The stalling will impact the servicing of interrupt and peripherals, this can be quite problematic for serial data transfers.

Calling a routine for each 16-bit word is also rather inefficient, there is no need to keep toggling the program bit.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..