FLASH use in STM32F207

[Barbie]

Posted on December 19, 2012 at 15:24

I want to use the FLASH to write some data for use after power up.

1. Is there a small section I can use for some bytes (4) without involve with the CODE flash?2. If not how can I take 1 section of the flash and be sure the code won't write to there?3. Where I can fine a sample show me how to select a sector /block it to code write/ write & read from there during the run time?RegardsBar. #flash-on-stm32f207

[Tesla DeLorean]

Posted on December 19, 2012 at 15:46

For speed and practicality the second 16KB sector might be the most effective.

Depending on your tools you would need to carve out a space in the memory map, via say the target GUI, scatter file, or linker script. It is the linker that places the code. Another approach would be to use the first 16KB sector as a boot loader, and start your application at the third (0x08008000) If you use the internal flash be aware that it will stall CPU execution of code running from flash as you erase/write other areas.

[frankmeyer9]

Posted on December 19, 2012 at 16:27

I suggest to have a look at external serial EEPROMs, especially for commercial applications. They allow byte-wise erase/write, and survive at least 10 times more erase/write cycles, compared to Flash.

[Barbie]

Posted on December 20, 2012 at 14:10 Hello Clive. It is strange. I look on ST example for FLASH program and I see they use sectors 2-5 . But in there link config they allow ROM as this: /*-Memory Regions-*/ define symbol __ICFEDIT_region_ROM_start__ = 0x08000000; define symbol __ICFEDIT_region_ROM_end__   = 0x080FFFFF; define symbol __ICFEDIT_region_RAM_start__ = 0x20000000; define symbol __ICFEDIT_region_RAM_end__   = 0x20020000; So how they don't have corrupt between the code taht can be lay on the same segment of the FLASH program by the application? Regards.Bar.

[Tesla DeLorean]

Posted on December 20, 2012 at 15:04

I think that's the hope & pray strategy, where they know the code isn't big enough to intrude into the space they are playing with.

Normally you'd have to describe two ROM regions (IROM1, IROM2 say) with a gap between them. In your example you could also shrink the size of the singular region so the area being erased/written/read is above the limit the compiler/linker is using. Remember these are limits expressed to the software, and the hardware functions as before. In other situations you'd use high memory addresses, but frankly the 128KB sectors are SO SLOW to erase (couple of seconds worst case according to docs) that you have totally lost real-time responsiveness, and peripherals will over/under run. The best time to do erasing is probably at reset, and/or have your writes to flash ''journal'' over the already blank areas, rather than have the saved parameters in a fixed location, ie find the last written values. Be aware that current F2 parts have a die with 1MB of flash on them.