FDS_EVT_GC results in NRF_SUCCESS but with remaining freeable words

Hello, 

We have nRF52832 in production on a custom board. Recently, we created a new functionality with the aim to handle flash more efficiently, and to avoid the case where peer manager will not have enough space and it will erase bonds. So, every time before saving any kind of record, words_used + new record size is checked that is less than the determined limit and then saving in flash is allowed. We also call two times a day the fds_gc, as long as there is no BLE connection at the time. 

The problem is that from many clients devices we receive logs that we have set in order to track gc behaviour. This kind of log is set after FDS_EVT_GC and if this event returns NRF_SUCCESS. In this case we call fds_stat to witness the result of garbage collector, but unfortunately, it returns the same number of freeable words at every gc call. We have this log from many users for days, and we do not know why this happens, and why it doesn't delete all freeable words but still returns nrf_success? 
When I say the same number I mean same number again and again for each user, e.g. one user has 1458, another 2012, etc. 

Why does this happen?
How can we solve this problem? 

Thank you in advance.

Dimitra

  • Hi,

    Which nRF5SDK version are you using?

    Would it be possible to share a minimal sample that would reproduce this issue? Alternatively share a flash dump before and after garbage collection using:

    nrfjprog --readcode dump.hex

    I can make the case private first if you prefer it. 

    regards

    Jared

  • Hello, 

    We use nRF5 SDK 17.1.0, softdevice s132, and SEGGER Embedded Studio. 

    I am currently running tests to reproduce it myself, as I said we have seen it mostly on release on client's devices in which we have some logs to check the functionality remotely. 
    As soon as I confirm how to reproduce the problem, I will share it with you. 

    In the meanwhile, could you please explain to me what you mean by flash dump and how to do what you describe with this spesific command too? (I haven't used command line, I edit on SEGGER and erase/write hex through nrf Connect app programmer). 

    Regards, 
    Dimitra

  • DimitraN said:
    In the meanwhile, could you please explain to me what you mean by flash dump and how to do what you describe with this spesific command too? (I haven't used command line, I edit on SEGGER and erase/write hex through nrf Connect app programmer). 

    nRF Command Line tools is a stand alone executable that contains several options to communicate with the debug interface on the nRF52. One of these commands --readcode allows you to read the flash on the nRF52 and stores the content in a file. You can find documentation for it here.

  • Hello, 

    I have been running tests to reproduce the log but I am still not sure what causes it. 

    Let me explain more:
    We have made a test function that saves multiple fake samples to force flash getting full in order to test the operation when it gets full. 

    Two times I saw this error with GC:
    1. I did this test , the flash got full, meaning we stop attempting to save anything in flash, we call GC in case there are freeable words, we free up some space, GC worked fine, and then we continue to save some more records, until there is nothing to delete and there are no freeable. 
    Then, I powered down my board, trying to see if running out of battery might be relevant to the case. 
    Turned the board back on, and connected with mobile to collect data. When we collect data, the records are deleted from flash. After getting all data, I disconnected, and GC is called which now had over 22000 words to free. The result was unfortunately, that GC finished successfully with 2040 freeable not erased. 
    I did hard reset and GC was called again and this time it resulted in 0 freeable words. 

    2. The second time the bug occurred I have no idea why it occurred. I was repeating this test, and when the flash got full and GC was called it returned successfully with 528 freeable words not erased, before I turn off the power... And I don't see anything different on the logs that would help me understand why now it occurred earlier. 
    I connected to collect data, after receiving them, GC was called again and now it had 2040 freeable left in memory again... 

    Do you think I should do soft-reset when it gc returns SUCCESS but there are freeable remaining records?

    Finally, I tried running the command you told me but I get this: 
    [error] [ Worker] - BinaryImage access error, could not open dump.hex.
    [error] [ Client] - Encountered error -162: Command read_to_file executed for 6401 milliseconds with result -162
    ERROR: The file specified is not a valid hex file, has data outside valid areas
    ERROR: or does not have data in valid areas.
    NOTE: For additional output, try running again with logging enabled (--log).
    NOTE: Any generated log error messages will be displayed.

    What am I doing wrong?

    If I run device version it seems connected... 
    PS C:\Program Files\Nordic Semiconductor\nrf-command-line-tools> nrfjprog --deviceversion
    682245179 - NRF52832_xxAA_REV1

    Thank you for your support.

  • Hi,

    Can you double check that you have read write access in the path that you are trying to run that command from? Alternatively, try changing the filename to something else. 

    regards

    Jared 

Related