This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

FDS GC seems not to work

Using SDK 13 FDS, I store 6468 byte, that is 1617 words, including FDS header. Of course this size is total. In detail in byte size, this size consists of

(12(header)+ 576) * 7
(12 + 774) * 1
(12 + 691) * 2
(12 + 144) * 1

I set FDS_VIRTUAL_PAGE_SIZE to 1024 and FDS_VIRTUAL_PAGES to 3.

Then, first write with fds_record_write() is success.

However, second write, that is update, with fds_record_update() fails with FDS_ERR_NO_SPACE_IN_FLASH.

I call fds_gc everytime after fds_record_write () or fds_record_update() call.

I assume that fds_record_update() marks the current record as deleted one and write data to new record area, then calling fds_gc() makes the record area marked as deleted available again.

But when I print out debug log in page_has_space() in fds.c, write_offset of page is only incremented, and FDS doesn't seems to reuse deleted page.

Is my thought correct? If so, this phenomenon is bug? If not, how should I update my data?

Thank you.

Parents
  • Hi,

    Running GC after fds_record_write() has no effect.

    Running GC after fds_record_update() will delete the 'old' copy of the record, if it succeeds.

    To have an 'old' copy of the record the fds_record_update() call must have returned FDS_SUCCESS synchronously and then sent out an FDS_EVT_UPDATE event indicating FDS_SUCCESS. Otherwise, the operation is not performed and thus no 'old' record that can be garbge collected is present in flash.

    My understanding is that you are not actually able to create a new, updated copy of a record because the fds_record_update() call returns FDS_ERR_NO_SPACE_IN_FLASH which indicates that there is no space for the new copy, therefore the record can't be updated and the 'old' copy marked as dirty.

    Regards, emdi

  • I believe peer manager uses 1 full FDS page by itself, so it is normal that you get NO_SPACE_IN_FLASH when trying to update everything at once, because there is no enough room. But as you state, GC should be able to delete those two records that you already updated and let you update one more... then GC is failing... are you sure there is no record opened at the moment you call gc? please copy here your FDS interrupt handler. Are you reading flash records at any moment? What is your BLE activity?

Reply
  • I believe peer manager uses 1 full FDS page by itself, so it is normal that you get NO_SPACE_IN_FLASH when trying to update everything at once, because there is no enough room. But as you state, GC should be able to delete those two records that you already updated and let you update one more... then GC is failing... are you sure there is no record opened at the moment you call gc? please copy here your FDS interrupt handler. Are you reading flash records at any moment? What is your BLE activity?

Children
No Data
Related