┬ÁTasker Forum

┬ÁTasker Forum => NXPTM M522XX, KINETIS and i.MX RT => Topic started by: AlexS on June 01, 2018, 12:53:58 PM

Title: Recommended route for storage (low-level flash routines or filesystem)
Post by: AlexS on June 01, 2018, 12:53:58 PM

As I have mentioned before, I'm currently working on porting a project based on Processor Expert and Code Warrior, running on a K22 to uTasker. In the PE project, the storage solution chosen was based on a basic storage system written from scratch that ran on top of PE's drivers for the MCU's internal flash. It worked (and still does) great. Before I ask my question, I'll briefly describe the storage mechanism:

1. Data that I need to store is essentially a collection of entities, serialized at different sizes, each uniquely identified through an ID.
2. On device power-up, the storage routines would try and load a basic storage system control structure from a predefined address in flash. That control structure would contain a set of entries, each offering a data entity id, offset in flash  and size of the stored data.
3. For each of the data entities, it would go at the specified offset, load the specified entity, check its integrity and deserialize it.
4. During the normal operation of the device, those entities might be modified externally, operation which would trigger the storage system to erase and then update that entity's flash serialized version.

My first instinct was to use the low-level flash routines. One downside is that I'll need to add a driver on top of that to backup the other data in the sector(s) to be erased. Not a big problem, but that got me thinking if it wouldn't be better to use the built-in file system for added functionality down the line.


Title: Re: Recommended route for storage (low-level flash routines or filesystem)
Post by: mark on June 01, 2018, 04:06:57 PM
Hi Alex

You have a number of possibilities.

- First of all you could use your existing code as it is - you just need to keep the code and its headers separate so that there are no conflicts when building.
Eg. You build your files using your headers and add a extern routine which executes the operations, which is called from the uTasker part (where you add a corresponding prototype in one of its header files, or local to the code that is going to call it). If you disable uTasker flash support with NO_FLASH_SUPPORT in config.h it will ensure that there is no risk of trying to use the same areas of Flash

- Secondly you could use your existing higher level code and use the low level flash routines in the project, which would ensure that you could simulate the operation and it would remain compatible if you change processors later.

- Thirdly you could use the uParameterSystem by adding your parameters to it, which will allow you to use the fail-safe swap block (and optional temporary validation) capabilities. This would also ensure simulation and compatibility.

- Fourthly you may prefer to save different clocks in uFileSystem files which would probably be about the same as you presently do. This allows you to easily write to files and erase them when needed (essentially re-writing to an existing file causes an automatic erase to take place).

The low level routines, uParameterSystem and uFileSystem are all described in http://www.utasker.com/docs/uTasker/uTaskerFileSystem_3.PDF
These also allow operation in data flash (if using FX or DX parts) or allow the same operation in various SPI Flash devices as well in case external storage were to be added.

The integrated Flash operations can be tested at the command line menu (in the I/O menu) whereby the concept is shown in this video: https://www.youtube.com/watch?v=Pe9A8qsefzQ&index=13&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&t=25s

Good luck


Title: Re: Recommended route for storage (low-level flash routines or filesystem)
Post by: AlexS on June 04, 2018, 12:14:25 PM

Will choose between options #2 and #3. The uParameterSystem looks very tempting. As I said, my stored data is essentially a collection of serialized entities built dynamically at startup, depending on the software version. Given that my data is ~10kBytes in size, if I want to update 100bytes in the middle of the parameter block, would it erase all flash sectors contained in the parameter block or just the one in which the data that I want to edit resides? Worried about flash wear.
Title: Re: Recommended route for storage (low-level flash routines or filesystem)
Post by: mark on June 04, 2018, 02:47:38 PM

10k is probably too large for the parameter block since it does a complete swap each time to save.
Also, it allows individual byte writes, requiring the storage to use a long word per byte (or an 8 byte phrase for some chips) and so will occupy 4 to 8 times the space.
There is an option called PARAMETER_NO_ALIGNMENT which doesn't align each byte to a storage element but needs the user to make sure that writes are not attempted on non-aligned boundaries.
It may be best to use multiple files containing blocks of parameters/data equal to the size of flash segments so that each time a file is updated only its segment if involved in erase/write operations.