FDS - missing swap page

[Wojciech Jasko]

 Hi,

One of our devices is bricked due to the fds_init returning FDS_ERR_NO_PAGES. After flash analysis, I have discovered that all pages are marked as FDS_PAGE_DATA (no FDS_PAGE_SWAP). One of these pages is erased (just FDS_PAGE_TAG_MAGIC and FDS_PAGE_DATA header).

In our application, FDS is heavily used. During testing, we perform many power cycles. I do not have any clear reproduction path due to the fact that we found it just once (more than 200 devices online for a few months).

We are using SDK 14.2.0 with nRF52832 (custom board designs).

FDS flash dump can be found here: https://drive.google.com/drive/folders/1y_KOyIhVw9d-ZAAIc8SSa8k9vUOobDVz?usp=sharing

[Wojciech Jasko]

Hi,

Good news:) I have a way to reproduce it.

Given we have interrupted the GC procedure (power off) in the following state:

| page_address | page_type  |
| 0xEF000      | erased     |
| 0xF0000      | data       |
| 0xF1000      | swap_dirty |
| 0xF2000      | data       |
| 0xF3000      | data       |

When we initialized fds again it performs the following actions (PROMOTE_SWAP_INST):

• tag 0xF1000 as the data
• tag 0xF0000 as the swap (this fails due to NAND flash)
• tag 0xEF000 as the data

When the erased page is initialized before swap page then m_gc.cur_page is not initialized correctly. This is my proposition:

            case FDS_PAGE_SWAP:
            {
                if (swap_set_but_not_found)
                {
                    m_pages[page].page_type    = FDS_PAGE_ERASED;
                    m_pages[page].p_addr       = m_swap_page.p_addr;
                    m_pages[page].write_offset = FDS_PAGE_TAG_SIZE;

                    m_gc.cur_page = page; // FIX
                    page++;
                }

                m_swap_page.p_addr = p_page_addr;
                // If the swap is promoted, this offset should be kept, otherwise,
                // it should be set to FDS_PAGE_TAG_SIZE.
                page_scan(p_page_addr, &m_swap_page.write_offset, NULL);

                ret |= (m_swap_page.write_offset == FDS_PAGE_TAG_SIZE) ?
                        PAGE_SWAP_CLEAN : PAGE_SWAP_DIRTY;
            } break;

It is fixing this case, but I am not sure if it does not break anything. Please, could you review it for me?

[Edvin]

Hello Wojciech,

Thank you for coming back to us. I am sorry I didn't reach out, but it is hard to keep track of old cases with no activity. The bug (the cause) was actually found some time before the release of SDK16. The fix looks quite similar (if not identical). You can compare it to the fds.c file in SDK 16.

Best regards,

Edvin

[Min-Joon Kim]

Dear Edvin,

I've upgraded the SDK and tested.

Unfortunately, I still have the same problem, the no swap page issue.

The test procedure was as follows:

1. I run a code doing "write and garbage collection" continuously.

2. During the process, I turned off the power.

3. After a while, turned on.

4. Then, from time to time, I found "no swap page" after fds_init().

   (I couldn't dump the hex file before fds_init().)

5. As you know, if there is no swap page, fds_init() looks not fully successful and we cannot access to FDS.
    After that, bricked at the next boot.

Best regards,

Min-Joon Kim.

[Edvin]

Min-Joon Kim: 
Please create a new ticket and upload the flash dump in that ticket. 

 

Min-Joon Kim said:

 (I couldn't dump the hex file before fds_init().)

 No need. Just dump it after the fds_init() that returns "no swap page". Perhaps it gives some information as to why it can't initialize.

BR,

Edvin

[Min-Joon Kim]

Edvin,

The flash dump was very simple.

All the three pages were tagged as data page.

Two pages had no record.

One page had some records that were very normal as I wrote.

When I changed the tag of one data page having no record to swap,

it worked well.

Thanks.

Best regards,

Min-Joon Kim.

[Jason Wright]

I have also experienced this issue with SDK 17.0.2. On one device calls to fds_init during boot returned the NO_SWAP error. Looking at the memory contents all the FDS pages were tagged as DATA.