This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SDKV12 fstorage documentation change request

As of SDKV12, because of the removal of pstorage, I upgraded my app to use fstorage.

If you look at the SDKV12 doc at this link, you will notice that it is quite lacking in that it doesn't have any narrative about usage: infocenter.nordicsemi.com/.../group__fstorage.html

As such, I clicked the SDKV11 doc at this link, and read the helpful narrative: infocenter.nordicsemi.com/index.jsp

Unfortunately, after following the instructions, I wrote incorrect code which took me a while to debug. Under "Priority for flash usage" it says: "For each module registration, you must specify the priority with which fstorage assigns flash space to the module. Possible values are 0 to 255, where 255 is reserved for usage by the Peer Manager. "

And so, because of this, I used the value 0.

That was a mistake.

If you look at fstorage.c, in fs_init(), you will see that it initializes a field "max_priority = 0" and does a later comparison of "if (p_config_j->priority > max_priority)". Because of this test, if an entry's priority is == 0, the entry's start and end addr are never initialized.

The fix can be done in the documentation; a code change is not necessary.

Please change the doc to say simply "Possible values are 1 to 254".

  • Aren't you comparing different sections? Or did I misunderstand you?

    The Fstorage usage documentation can be found here in SDK 12.

    The Fstorage usage documentation can be found here in SDK 11.

    It seems to me that priorty 0x00 works. The start and end addresses are still set. Aren't they?

  • You're right about the doc; thanks.

    But the SDK12 fstorage documentation has the same text, stating that the valid range is 0-255 with 255 being reserved by peer manager.

    Priority 0x00 most certainly does not work. The start and end addresses are not set.

    In my app I had a single fstorage declaration with prio==0.

    When I debugged why the start/end were never being set in the fs_config, I followed the flow of the nested loops in fs_init and it became immediately clear what the bug was:

    In my example, the two in the config table were, in this order, a) mine with pri==0, and b) pm's with pri==0xff.

    On the first iteration of the outer loop (i==0), the inner loop validly finds peer manager's 0xff entry (j==1) as being the highest priority, and assigns its addresses.

    On the second iteration of outer loop (i==1), the bug manifests itself:

    1. On the first iteration of the inner loop (j==0), the addresses of my entry are null (so it doesn't do the 'continue'), HOWEVER because my priority is == 0, it fails the test "if (p_config_j->priority > max_priority)" because 0 (my priority) isn't > 0 (the max_priority initialization value). Thus, the max_priority and max_indexes are NOT set to point to my entry.

    2. On the second iteration of the inner loop (j==1), the addresses of the pm entry are non-null, so it continues, and then exits the loop because there are no more entries to process.

    Then, when falling out of the loop, max_index==i==1 (because we fell out of the loop without setting max_index), and so instead of updating my entry, it re-writes the addresses of the pm entry a second time!

    The bottom line is that pri==0 is not supported given this code in fstorage.c.

    If this isn't clear, please tell me and I'll try explaining again. It really is a bug.

  • I think this is clear enough and it is a bug.

    Anyways, if you are migrating from pstorage I'd suggest you to have a look at the flash data storage (fds) module which provides a more similar abstraction level to pstorage than fstorage, which basically is just a flash driver.

    Unless you were using the pstorage_raw implementation, then fstorage will do the work.

    Hope this helps,

    E

  • I totally agree. We will fix this, thanks for reporting :)

Related