FDS driver issue

[khodidas]

Hello,

Hope you guys are well !!!

We are using below SDK's for our range of product:

1. 11.0.0

2. 13.0.0

3. 13.1.0

4. 14.1.0

5. 15.2.0

6 15.3.0

As I come to know that you guys fixed issue of FDS in SDK16.0.0.

nRF5 SDK v16.0.0
------------------------
Release Date: October, 2019

*** Bug fixes
****************

** Drivers and libraries **

- FDS: fixed two bugs where a power loss at very specific times during garbage
collection could corrupt the file system, making FDS unable to initialize and return
FDS_ERR_NO_PAGES on initialization.
- FDS: fixed a bug that prevented using the last word of a flash page to save a record.

How can we fix this issue in above mention SDK we are using?

Do we have guide line to fix issue?

Thanks,

Nirav Patel

[Jørgen Holmefjord]

Hi,

It will be hard to explain the changes into the older SDKs, but I compared fds.c in SDK 15.3.0 and SDK 16.0.0, and the changes are the following:

The following function in SDK 15.3.0:

static bool page_is_erased(uint32_t const * const p_page_addr)
{
    for (uint32_t i = 0; i < FDS_PAGE_SIZE; i++)
    {
        if (*(p_page_addr + i) != FDS_ERASED_WORD)
        {
            return false;
        }
    }

    return true;
}

Has been replaced with the following function in SDK 16.0.0:

// A page can be tagged if it is entirely erased, or
// of the first word is fds magic word and the rest of it is erased.
static bool page_can_tag(uint32_t const * const p_page_addr)
{
    // This function should consider pages that have only the first half
    // of the fds page tag written as erased (taggable).
    // That is because the tag is two words long, and if the device
    // has rebooted after writing the first word, that would cause
    // the page to be unusable (since undefined and not fully erased).
    // By considering the first word as erased if it contains fds page tag,
    // the page can be re-tagged as necessary.

    if ((p_page_addr[FDS_PAGE_TAG_WORD_0] != FDS_ERASED_WORD) &&
        (p_page_addr[FDS_PAGE_TAG_WORD_0] != FDS_PAGE_TAG_MAGIC))
    {
        return false;
    }

    // Ignore the first word of the tag, we already checked that it is either erased or fds's.
    for (uint32_t i = FDS_PAGE_TAG_WORD_1; i < FDS_PAGE_SIZE; i++)
    {
        if (*(p_page_addr + i) != FDS_ERASED_WORD)
        {
            return false;
        }
    }

    return true;
}

And the function call is replaced inside pages_init().

There is also an addition further down in pages_init(), in the FDS_PAGE_SWAP case:

// This is a candidate for a potential new swap page, in case the
// current swap is going to be promoted to complete a GC instance.
m_gc.cur_page = page;

The header_check() function is also slightly modified, to check for erase word:

// It is important to also check for the record ID to be non-erased.
// It might happen that during GC, when records are copied in one operation,
// the device powers off after writing the first two words of the header.
// In that case the record would be considered valid, but its ID would
// corrupt the file system.
if (   (p_hdr->file_id    == FDS_FILE_ID_INVALID)
    || (p_hdr->record_key == FDS_RECORD_KEY_DIRTY)
    || (p_hdr->record_id  == FDS_ERASED_WORD))
{
    return FDS_HEADER_DIRTY;
}

Hope this helps.

Best regards,
Jørgen

[Jørgen Holmefjord]

I'm sorry, but I think you are stuck with me:

The FDS fixes in SDK 16 is described above. We will not backport these to older SDKs, and it will be hard to trace it back to every SDK version that you mention. You have a few options:

• Port the older projects to SDK 16.0.0 (or SDK 17).
• Backport the FDS library from SDK 16.0.0 to the older SDKs. For older SDKs, this may not be trivial as FDS may depend on other libraries.
• Try to backport the fix to the FDS library in the older SDK versions. Some of the code in the older SDK versions will be similar to the changes mentioned above. It may not be that hard to do for some of the more SDK recent versions.

[khodidas]

Hi Jorgen,

I am really sorry. I missed your badge. 

Yes, for recent SDK version, I can manage it as changes are not that much.

However, our many products are still on SDK 11 as they are based on nRF51. It is very difficult to backport the fixes. 

Can you please help only for SDK11? Rest I will manage.

[khodidas]

Hi Jorgen,

Are you working on my problem?

[Jørgen Holmefjord]

Hi,

I'm not sure exactly what you want us to do. We can provide you a diff between the SDK 11 and SDK 12 FDS libraries, but I believe that you are able to get that yourself. 

Unfortunately, there are no plans to backport the fix to SDK 11, your options are either to port your project to a more recent SDK where the fix is included, or backport the fix to SDK 11 yourself. I understand that it is a big job to do this, but this is a very old SDK version that is not much used anymore.

Are you seeing this issue in the product(s) running SDK 11? If not, I do not know if it is worth the effort to add the fix, as the product most likely has been running fine for many years.

[khodidas]

Hi,

Actually, my friend is facing flash corruption issue after device runs ok for several month. We are not sure if it is FDS library which is causing issue.

My devices are running fine as of now. But I came to know that FDS has issue which can corrupt data so wanted to backport fixes.

Ok. I decided to not backport fixes until we face some flash related issue.

Thanks for you help!