Skip to main content
shotaro
shotaro
Associate III
November 20, 2012
Question

Ways to speed up writing to program flash

  • November 20, 2012
  • 13 replies
  • 5849 views
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.
    This topic has been closed for replies.

    13 replies

    shotaro
    shotaroAuthor
    Associate III
    November 21, 2012
    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
    Andrew Neil
    Super User
    November 22, 2012
    Posted on November 22, 2012 at 07:27

    ''optical-based software updates''

     

    Sounds fascinating! What do you mean by that?
    A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
    charlieincanada69
    charlieincanada69
    Associate III
    January 9, 2013
    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
    charlieincanada69
    Associate III
    January 9, 2013
    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
    jpeacock2399
    Associate III
    January 10, 2013
    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
    charlieincanada69
    Associate III
    January 10, 2013
    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
    M0NKA
    Associate III
    January 11, 2013
    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
    charlieincanada69
    Associate III
    January 11, 2013
    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... ;)

    Tesla DeLorean
    Tesla DeLorean
    Guru
    January 11, 2013
    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 (See Profile) Up vote any posts that you find helpful, it shows what's working..
    charlieincanada69
    charlieincanada69
    Associate III
    January 11, 2013
    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).

    Show more replies
    Terms & ConditionsAccessibility statement