2012-11-20 02:33 PM
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.2012-11-21 10:13 AM
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.2012-11-21 10:27 PM
''optical-based software updates''
Sounds fascinating! What do you mean by that?
2013-01-09 05:46 AM
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!2013-01-09 08:33 AM
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.2013-01-10 06:55 AM
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 Peacock2013-01-10 09:04 AM
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 functionFLASH_ProgramHalfWord
to do the writing. Looking through the code I wonder if it is getting delayed in theFLASH_WaitForLastOperation
call... Any other ideas/tips are welcome!2013-01-11 12:46 AM
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 ? BR2013-01-11 08:58 AM
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... ;)2013-01-11 10:29 AM
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.