What is the best way to store, retrieve, change program configuration data?

[Mike Hooper]

Posted on August 31, 2017 at 17:05

I need to store approximately 128 bytes of 'factory default' configuration data in

FLASH

when the program is initially loaded into my STM32F7xx custom board during production. Then, when the program boots, I need to load this data into ram-based variables for manipulation during program execution. At any time during program execution the values of these variables can be changed by the program. If/when they are changed, I would like to update their stored values in FLASH.

I have implemented this previously in a TI processor by defining a special section of FLASH memory for this purpose. The TI processor permitted erase/write of small segments (128 bytes). But apparently the STM32F7xx minimum erase size is a segment. The smallest segment in an STM32F7xx is 32KB, which is much larger than my config data. And the smaller segments are located in low memory where the linker normally loads the beginning of the program data. So it seems like I need to store my small amount (128 bytes) of config data in the upper 256k bytes of FLASH. Seems like a bit of a waste to me.

Is there a better way to implement this config data storage? Guidance appreciated.

[waclawek.jan · Accepted solution]

Posted on August 31, 2017 at 17:12

Is there a better way to implement this config data storage?

'Better' is a relative word. Consider:

- external 24Cxx EEPROM (or like)

- battery-backup and then either the RTC backup registers or the backup SRAM if present in your STM32 model

JW

[Mike Hooper]

Posted on August 31, 2017 at 17:36

Thanks Jan. Seems reasonable.

[Mike Hooper]

Posted on September 14, 2017 at 20:06

I just wanted to do a sanity check on my chosen solution.

I have decided to try a FRAM chip (Cypress FM25L16B) for parameter storage. The FRAM seems to have several advantages over EEPROM or storing in STM32F7xx flash.

Advantages:

Reads and writes are at 'bus speed' vs EEPROM several milliseconds..

Very high endurance as compared to EEPROM or flash.

Disadvantages:

Much higher price than EEPROM ($1.85/100pcs vs $0.78/100pcs).

Does anyone have any other thoughts on this? I have never used a FRAM chip and would like to hear others experiences before making a final commitment.

Thanks!

[AVI-crak]

Posted on September 14, 2017 at 21:32

Read the block, change the block, erase the block on the flash, record the changed block.

The program of writing should be copied into memory, and not having dependencies with the program on the flash.

Sorting the contents of a flash is very difficult, it's much easier to write an isolated program.

[David Littell]

Posted on September 14, 2017 at 20:30

Mouser shows $1.26/100.

[Code Wrangler]

Posted on September 15, 2017 at 00:15

You can tell the linker to avoid the 32k Flash block when generating the code (better 32k lost than 256k) and use that for your parameter values. Unfortunately, editing the memory map is compiler specific, so I can't give exact instructions.

The wear issue is not real. You can store 128 bytes 256 times in a 32k block. Just keep writing them sequentially and only erase the block after you've filled up all 32k. That will give you a conservative lifetime of 256 * 100k = 25.6 million parameter block stores. And that's with a conservative 100k wearout limit - Most flashes can do much more than this.

But I agree with avi_crak's solution if you want to waste the absolute least amount of memory possible. It is somewhat susceptible to a power failure during update, so some care needs to be taken if that solution is chosen.

$1.26 seems like a high price to pay. I'd personally go with a $0.10 SPI Flash or I2C EEPROM chip if I absolutely was determined to store it off-processor.

[Mike Hooper]

Posted on September 15, 2017 at 13:01

Thanks for the comments on writing to flash folks. But what I am really more interested in now is hearing about experiences with FRAM (perhaps I should have started a new thread). Other than price, it seems like a slam-dunk better solution.