Hello, we are having a low occurrence issue when attempting to write some data in NVM using fstorage.
We are using a nRF52832 as a BLE peripheral using SDK15.2.0 and SoftDevice s132, also we're also using FreeRTOS.
Here's the relevant (modified) code we're using for writing:
#define NVM_DATA_ADDR 0x77000 static void wait_for_flash_ready(nrf_fstorage_t const *p_fstorage) { /* While fstorage is busy, sleep and wait for an event. */ while (nrf_fstorage_is_busy(p_fstorage)) { (void) sd_app_evt_wait(); } } static bool write_flash_data(void) { struct s_nvm_data nvm_data = get_nvm_data(); ret_code_t rc; if (memcmp(&nvm_data, (void *) NVM_DATA_ADDR, sizeof(struct s_nvm_data)) == 0) { return true; } rc = nrf_fstorage_erase(&fstorage, NVM_DATA_ADDR, 1, NULL); if (rc != NRF_SUCCESS) { return false; } wait_for_flash_ready(&fstorage); rc = nrf_fstorage_write(&fstorage, NVM_DATA_ADDR, &nvm_data, sizeof(struct s_nvm_data), NULL); if (rc != NRF_SUCCESS) { return false; } wait_for_flash_ready(&fstorage); if (memcmp(&nvm_data, (void *) NVM_DATA_ADDR, sizeof(struct s_nvm_data)) != 0) { return false; } return true; } void write_flash_task(void *arg) { bool success; init_fstorage(); for (;;) { if (semaphore_take(SEM_NVM)) { do { success = write_flash_data(); } while (!success); } } }
The semaphore is given when our device is in advertising (advertising interval is 200ms), after about 30 min the device is power off.
On power on reading back the data, we observed sometime that the nvm data were neither written nor erased (same value as before write attempt).
The task is configured as one of the lowest priority, though when attempting to write there is close to no other task running (except softdevice).
Would you be able to help us?
Hello,
It seems like this may be related to the bug discussed in this thread here: https://devzone.nordicsemi.com/f/nordic-q-a/39459/observer-under-freertos-events-stop-coming-after-a-few-minutes
To fix this, could you try to replace the Freertos files in your project with those from SDK 17.0.2 instead?
Hello, we already made this change as we had a similar issue a year back. So this fix is unrelated to our issue.
Could you try and see if you get the same result if you use the latest Freertos port from SDK 17.0.2 to rule out any other potential bugs that may have been fixed? It should be close to drop-in compatible so it should be easy to try.
ok we'll try using FreeRTOS port from SDK 17.0.2, though it'll take couple of days to test it because of the low occurence.
Sounds good, thanks. I just assumed you were able to reproduce this more consistently. I will try search for similar bug reports in the meantime and let you know if I find something that seems relevant.