Hi! I need to persistently store data in the device I'm developing, so I thought I would save it to flash. How can I do this? I didn't find anything in xpcc, so I would have to use some lower level functions I think, but what I don't know is how to allocate space for the data in the flash so it's on a separate page? Antal
Hi Antal, On 16/02/16 16:04, Szabó Antal wrote:
I need to persistently store data in the device I'm developing, so I thought I would save it to flash. How can I do this?
Yes, that is possible, ST has an application note about that [0]
I didn't find anything in xpcc, so I would have to use some lower level functions I think,
Yes, we have not implemented storing persistent data in flash yet. However, we would be more than happy if you want to work on an implementation. As many different micro controllers support writing to flash, I would suggest to separate the code into two layers: 1.) a low level hardware abstraction layer (HAL), that encapsulates low level access to the STM32 registers 2.) a high level layer that uses the HAL to access the flash and implements the required data organization and wear leveling techniques.
but what I don't know is how to allocate space for the data in the flash so it's on a separate page?
This probably has to be done in the linkerscript. I think Niklas can tell you best how to specify a separate flash section for data. Thank you for your great work! Kevin [0]: http://www.st.com/web/en/resource/technical/document/application_note/CD0016...
Hi,
I didn't find anything in xpcc, so I would have to use some lower level functions I think,
Yes, we have not implemented storing persistent data in flash yet. However, we would be more than happy if you want to work on an implementation.
As many different micro controllers support writing to flash, I would suggest to separate the code into two layers: 1.) a low level hardware abstraction layer (HAL), that encapsulates low level access to the STM32 registers 2.) a high level layer that uses the HAL to access the flash and implements the required data organization and wear leveling techniques.
+1. Might also be worth to take a look at the STM32 HAL drivers in the CubeF1 libraries. They are quite convoluted (they’re written for a context switching OS, with semaphores and the whole shebang), but maybe you can reduce them to something useful with which you can write a cheap prototype, before deciding how to proceed.
but what I don't know is how to allocate space for the data in the flash so it's on a separate page?
This probably has to be done in the linkerscript. I think Niklas can tell you best how to specify a separate flash section for data.
The way I see it, you have two choices for the physical arrangement of persistent memory: 1. Add another memory section to this linkerscript like so: https://gist.github.com/salkinium/10daa6eec7788aea1cae#file-stm32_ram-ld-L60... The alignment buffer is important, because you might not want to write a flash page that code is currently executing from. If you have very, very simple data, all of the same type (could be a struct, but should be ATTRIBUTE_PACKED), then you can create _one_ large array that fits into this section. However, there are some _significant_ drawbacks with this solution: 1. __persistant_start can change at any time. Can be easily fixed by setting it to a fixed address though. 2. If you have multiple symbols in this section, their order is not guaranteed. 3. the .persistent section would be overwritten on every programming. Not that useful for persistency. In short: Don’t do it this way 2. The saner alternative would be to use a data structure that serialises objects for you with a specification and tested implementations. Might have higher setup costs than the naive solution above, but it will probably pay off later. In short: Have a look at http://cbor.io. Niklas
2016-02-17 0:36 GMT+01:00 Niklas Hauser <niklas.hauser@rwth-aachen.de>:
However, there are some _significant_ drawbacks with this solution: 1. __persistant_start can change at any time. Can be easily fixed by setting it to a fixed address though. 2. If you have multiple symbols in this section, their order is not guaranteed. 3. the .persistent section would be overwritten on every programming. Not that useful for persistency.
In short: Don’t do it this way
Actually this seems like an ok solution for me. What I tought is to put all data that needs persisting into a struct, and save that to the flash. I would only rarely write to it (when turning off the device), that way I think I can get away with the limited rewriteability of the flash. (Let's say it's turned off every day in every year, which is really an overestimation. Then it would last for at least 10000/365 ~ 27 years.) Also, losing the data on reprogramming is not an issue, this is just to store settings.
participants (3)
-
Kevin Laeufer -
Niklas Hauser -
Szabó Antal