FDS update fails with radio driver and softdevice active

Question

Hello,

I am developing a BLE and IEEE 802.1.4 multiprotocol device. I implemented a parser to change some settings of the device. The configuration is updated with this piece of code:

    if (fds_record_find(CONFIG_FILE, CONFIG_REC_KEY, &desc, &ftok) == NRF_SUCCESS) {
        m_fds_write_in_progress = true;
        fds_record_update(&desc, &rec);
        NRF_LOG_INFO("update");
        NRF_LOG_FLUSH();
    } else {
        m_fds_write_in_progress = true;
        fds_record_write(&desc, &rec);
        NRF_LOG_INFO("write");
    }
    int i=0;
    while(i<100000 && m_fds_write_in_progress) {
        if (i++%10000 == 0) {
            NRF_LOG_RAW_INFO(".");
            NRF_LOG_FLUSH();
        }
        #ifdef SOFTDEVICE_PRESENT
            (void) sd_app_evt_wait();
        #else
            __WFE();
        #endif
    }
    NRF_LOG_INFO("done");

m_fds_write_in_progress is reset to false in the fds event handler

static void fds_evt_handler(fds_evt_t const * p_evt) {
    switch (p_evt->id) {
        case FDS_EVT_INIT:
            if (p_evt->result == NRF_SUCCESS) {
                m_fds_initialized = true;
            }
            break;
        case FDS_EVT_UPDATE:
        case FDS_EVT_WRITE:
            m_fds_write_in_progress = false;
            NRF_LOG_INFO("FDS update/write done");
            NRF_LOG_FLUSH();
            break;

        default:
            NRF_LOG_INFO("FDS evt %d", p_evt->id);
            break;
    }
}

When the parser is called from nrf_802154_receive() the fds_evt_handler isn't called while I wait for it in the while loop. Log output:

00> <info> app: update
00> 
00> ..........<info> app: done
00> 
00> <info> app: FDS update/write done

When I send the configuration String via UART the Log is as it should be:

00> <info> app: update
00> 
00> .<info> app: FDS update/write done
00> 
00> <info> app: done

Why is the behaviour different?

Jørgen Holmefjord · Accepted Answer

Hi, 
 Most likely the nrf_802154_receive() function is running in an interrupt context with higher (or equal) priority than the FDS/Fstorage event handler. The FDS handler is blocked by the current interrupt context until the while loop "times out" and the function exits. Once the receive-handler exits, the FDS/fstorage interrupt is processed. 
 It is not good practice to stay for extended periods of time inside interrupt context handler. You should rather set a flag to process the flash write in main context, or use app_scheduler to schedule event handling later. 
 Best regards, Jørgen

FDS update fails with radio driver and softdevice active

Top Replies