FDS leaves a "hole" in flash?

[Øyvind]

Hi,

I have seen some curious behavior with the FDS module. I'm using nRF5SDK 14.2.0 with s140_nrf52840_5.0.0-2.alpha, with FreeRTOS. In short: In some cases it seems that doing writes/updates that collide somehow will leave "holes" (0xFFFFFFFF where a record should have been) in the flash, which leads to everything beyond this "hole" cannot be found, yet all new writes/updates are written beyond the hole.

What I do:

• I have one module using FDS to update file/record 0x200/0x300 with data 0x123 or 0x456. This is a one word write. It first does a fds_record_find() to see if the file/record exists an if it does, updates it. If it doesn't exist, it writes it.
• Then I have another module asynchronously (running in another FreeRTOS thread) updating file/record 0x205/0x305 with 0x789, also only one word writes (however this write is not visible in the flash dump below).
• FDS_THREADS is defined to 1.
• FDS_OP_QUEUE_SIZE is defined to 4.
• Directed advertising is started every 2 seconds in a third thread, to deliberately disturb the flash access.

Below is an excerpt from a flash dump after I see this issue, and you can see the "hole" at 0xFC2F8, after which the 0x200/0x300 record can no longer be found and my code repeatedly writes a new entry.

0x000FC288: 00010000 0FDE0200 00000029 00000456   |........)...V...|
0x000FC298: 00010000 C7AB0200 0000002A 00000456   |........*...V...|
0x000FC2A8: 00010000 80780200 0000002B 00000456   |......x.+...V...|
0x000FC2B8: 00010000 47600200 0000002C 00000456   |......`G,...V...|
0x000FC2C8: 00010000 00B30200 0000002D 00000456   |........-...V...|
0x000FC2D8: 00010000 C8C60200 0000002E 00000456   |............V...|
0x000FC2E8: 00010000 9AD50200 0000002F 00000123   |......../...#...|
0x000FC2F8: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x000FC308: 00010300 39700200 00000031 00000123   |......p91...#...|
0x000FC318: 00010300 F1050200 00000032 00000123   |........2...#...|
0x000FC328: 00010300 B6D60200 00000033 00000123   |........3...#...|
0x000FC338: 00010300 71CE0200 00000034 00000123   |.......q4...#...|
0x000FC348: 00010300 361D0200 00000035 00000123   |.......65...#...|
0x000FC358: 00010300 FE680200 00000036 00000123   |......h.6...#...|
0x000FC368: 00010300 B9BB0200 00000037 00000123   |........7...#...|
0x000FC378: 00010300 60790200 00000038 00000123   |......y`8...#...|

I do suspect that this has to do with queueing of flash tasks as the issue seems to disappear if I reduce the queue size to 2, at least I haven't seen it then. Also, I have worked around this successfully another way by always do a readback after writing, and then if the file/record cannot be found, do a garbage collection and retry.

I have not been able to dive much deeper into what happens here, but I wanted to ask if this is a known issue with known workarounds. If not, I can live with my workarounds for now.

EDIT: typo

[Jørgen Holmefjord]

Hi,

Unfortunately, Flash storage, which FDS build on is currently not thread safe.

Best regards,

Jørgen

[Øyvind]

Thanks, I see. I guess I got confused by the inclusion of FDS_THREADS definition. Also, does the word "currently" indicate that this will be made thread safe soon?

Anyway, this seems to be stable enough for me with my mentioned workaround.

[Jørgen Holmefjord]

I can see the confusion, but this symbol only ensures that the library works with different users, like peer_manager and application, it does not ensure thread safe operations. We are looking into the possibility of making it thread safe, but this will require a very large amount of critical region sections, which will disable interrupts. I can't say anything about if or when this will happen.