STM32L151 Flash write speed

[stbbrad3]

Posted on October 12, 2012 at 15:35

Hello all,

I have a question about in application programming speeds with the L151. I have a working bootloader for both the L151 and the F207 micros. They are nearly 100% identical take a master/slave setup. For in application programming they will both serially receive a 526 byte packet with 512 bytes countaining actual program data. To the real question. Is it just me or does the flash write in the L151 take a ridiculously long amount of time? To write 512 bytes ( 1 word at a time ) it takes nearly 400ms. On the F207 I can write much, much faster(have not measured that, but easily 10-20 times faster). Anyone else have experience with this? I also find it weird that when erased flash is 0x00 instead of 0xFF.. this is the first chip I have ever worked with that does this. Let me show you a bit of the code that goes into programming the 512byte block. I do use the STM32 library.

uint8_t Flash_Write ( uint32_t StartAddress, uint8_t *p, uint32_t Size )

{       uint32_t idx;       uint32_t Address;       __IO FLASH_Status status = FLASH_COMPLETE;

      Address = StartAddress;

      /* Unlock the FLASH Program memory */

      FLASH_Unlock ( );           /* Clear all pending flags */            FLASH_ClearFlag ( FLASH_FLAG_EOP     |                         FLASH_FLAG_WRPERR  |                         FLASH_FLAG_PGAERR  |                         FLASH_FLAG_SIZERR  |                         FLASH_FLAG_OPTVERR );             while  ( Address < StartAddress + Size )       {             status = FLASH_FastProgramWord ( Address,  *(uint32_t *)p );             Address = Address + 4;             p = p + 4;             if ( status != FLASH_COMPLETE ) return status;       }

      /* Lock the FLASH Program memory */

      FLASH_Lock ( );

      return (uint8_t)status;

} And this is from the STM32L1xx_flash.c:

FLASH_Status FLASH_FastProgramWord(uint32_t Address, uint32_t Data)

{       FLASH_Status status = FLASH_COMPLETE;

      /* Check the parameters */

      assert_param(IS_FLASH_PROGRAM_ADDRESS(Address));         /* Wait for last operation to be completed */       status = FLASH_WaitForLastOperation(FLASH_ER_PRG_TIMEOUT);         if(status == FLASH_COMPLETE)       {             /* If the previous operation is completed, proceed to program the new  word */              *(__IO uint32_t *)Address = Data;                 /* Wait for last operation to be completed */             status = FLASH_WaitForLastOperation(FLASH_ER_PRG_TIMEOUT);             }       /* Return the Write Status */       return status; } The only documentation for timing I could find in the Flash Programming manual was for the data EEPROM and if the word has been erased (which is the case here as the entire application flash is erased before intiating the write) it takes 1 Tprog. What is a Tprog? There is no definiation of the time, or a way to calculate it in the Programmin Manual (PM0062). Anyone have any ideas or experience that can provide a way to reliably speed this process up? Thanks, Brad

[stbbrad3]

Posted on October 12, 2012 at 16:44 Well, My only guess is I need to get the flash write functioning placed into SRAM and call into them to speed up the flash writes. Sound right? Looks like I would have to do it somehow when the bootloader is launched as I would hate to suck up SRAM with fucntions not used by my application. My bootloader actually runs at power on to determine if the code checksum matches and will launch immediately if it does, otherwise when I command the bootloader to launch it waits up to 5 seconds to accept programming commands. Now I just need to figure out how to do that. Cheers, Brad

[Tesla DeLorean]

Posted on October 12, 2012 at 18:43

On the F1 I built a group of flashing functions in assembler which a parent function copied to RAM and then called. It's address agnostic code, so realistically I could carve out space on the stack, I just used some scratch space I wasn't using in the boot loader.

Yes, you definitely want to run in RAM, as it prevents the CPU stalling. You might also want to compare the current content of a location before bothering to write it, as that is very cheap. I also only turned on the PRG for the whole block, not at every word. The STM32L1, as I recall, has a flash errata about how it interacts with the CPU, which basically infers that instruction fetches get fouled up, thus you want to do a throw-away read of the flash array prior to executing code from it. Another reason to use RAM. I'm not sure of the efficacy of front and back checking if the flash is busy.