STM32L1xx Internal Flash Programming Problem

[rasimoguzturk]

Posted on April 19, 2014 at 10:28

Hi all,

I am working with stm32l100r8 target mcu for internal flash programming(data eeprom).When i program flash sector , i missed usart interrupt(115200 bd).In infinite loop i am writing data to some definite flash sector,during this operation usart interrupt not working i missed some data.

Is this a bug?

Thanks

[waclawek.jan]

Posted on April 19, 2014 at 13:25

You can't read from the FLASH bank which is written to. Your model has only one bank of FLASH. If the processor is attempting to fetch instructions from that bank, it is stalled until the write is completed.

If you don't want to use a model with large enough FLASH to have two banks, the only possible solution I know of is to move all the software which needs to run during FLASH programming into RAM. This might be non-trivial.

JW

[Tesla DeLorean]

Posted on April 19, 2014 at 22:51

Suggest using a protocol that does flow control, and write flash when you've accumulated a whole block, this way you aren't jamming up the processor when you expect to be receiving characters.

XMODEM-128 and XMODEM-1K work very effectively in this fashion when writing to flash, you hold off sending the ACK until the write is complete, and the host doesn't send any new data until you are done.

[rasimoguzturk]

Posted on April 20, 2014 at 12:02

Thanks for suggestions.

Yes clive1 that is a solution for  ''USART'' but what about the others?(EXTI,i2c etc).Is there any solution that covers all up?

This is a feature of that mcu,2k flash sector can be used as eeprom.Does not it necessary that eeprom programming has different procedure than normal flash in application programming?I am familiar with IAP,i tried it before on different stm32 mcu and i know bank1,bank2 things.While i was programming flash (IAP) i disabled interrupts.But eeprom programming is different than this,right?

[Tesla DeLorean]

Posted on April 20, 2014 at 15:40

It's generally smarter not to have such a noisy system when using FLASH, or faux EEPROM. As Jan suggests running everything from RAM is one of the most common strategies, and predates STM32 designs, in that FLASH has typically not permitted run-in-place while being erased/written.

If you need to keep changing things, the use of NVRAM would be preferable.