calling fds_write within a ble_evt_handler gets the SD or app stuck

RE: calling fds_write within a ble_evt_handler gets the SD or app stuck

Andy — Tue, 23 Apr 2019 11:42:47 GMT

And the problem with handling the write to flash in the event handler is that, if the write returns an error for one reason or another, there's no way to retry later but to wait for another BLE event.

RE: calling fds_write within a ble_evt_handler gets the SD or app stuck

Andy — Tue, 23 Apr 2019 11:40:59 GMT

There's the scheduler library. I don't know exactly which examples showcase its use though. It's pretty easy to use.

RE: calling fds_write within a ble_evt_handler gets the SD or app stuck

kobyatom — Tue, 23 Apr 2019 11:37:00 GMT

Thanks for helping so far. do Nordic have an example project of events/msgs getting sent to and handled in the main loop, maybe even inside a message-queue?

RE: calling fds_write within a ble_evt_handler gets the SD or app stuck

kobyatom — Tue, 23 Apr 2019 11:35:05 GMT

the proper way for me was to call fds_write from the ble_event, and skip waiting for it to complete. I add protection that returns err and doesn't call fds_write, in case the WRITE hasn't completed (fds_event_handler not called).

My FDS writing occur due to sporadic BLE write events, so there is no chance of any of them getting rejected anyway.

FDS writing from the ble_evt_handler context now works fine.

RE: calling fds_write within a ble_evt_handler gets the SD or app stuck

Andy — Tue, 23 Apr 2019 11:31:02 GMT

Mm good question, I couldn't find anything about it. Maybe the events are also generated by the softdevice since the FDS uses the SD as a backend.

We should probably wait for an answer from Nordic for this. In any case, the proper way to do it is to remove the write (and the while loop) from the event handler and write to flash later from the main context.

RE: calling fds_write within a ble_evt_handler gets the SD or app stuck

kobyatom — Tue, 23 Apr 2019 10:46:52 GMT

how do I change the interrupt priority of the FDS module?

RE: calling fds_write within a ble_evt_handler gets the SD or app stuck

Andy — Tue, 23 Apr 2019 08:54:47 GMT

Well, what's the benefit of having non-blocking APIs if you're wrapping them in while loops and waiting for the operation to finish? You're effectively converting the non-blocking code into blocking code.

Also, I'm not sure if I understood correctly, but I think you have those while loops in the ble_evt_handler. As I said, if the interrupt priority of the FDS module is lower than the BLE priority, the FDS event won't ever preempt the BLE event, and therefore the flag won't ever be set. You would just be stuck in a while loop in the BLE event handler forever, and since you're already in the event handler, no other events can be processed.

Lastly, you don't know how long the write operation is going to take. That's up to the softdevice to decide and it depends on how busy it is.

RE: calling fds_write within a ble_evt_handler gets the SD or app stuck

kobyatom — Tue, 23 Apr 2019 08:09:48 GMT

fds_record_write is async and non-blocking. It causes a callback to be called when the write is complete

after calling fds_record_write, I wait in a sleep-loop (not busy-loop) using

    while (fds_write_in_progress)
    {
        nrf_pwr_mgmt_run();
    }
    
    // or
    
    while(fds_write_in_progress)
    {
    #ifdef SOFTDEVICE_PRESENT
        (void) sd_app_evt_wait();
    #else
        __WFE();
    #endif
    }

If there is only 1 task in the SoftDevice, which is responsible for handling ble_evt_handler and the fds event handler, then it will indeed block, since it will not get the chance to respond to the fds event.
But, since my write operation is short (several bytes, which take a few microseconds which I believe the SD can spare), and I would like to keep my code simple, I hope there is a way to create a 2nd thread, one that will be coupled with the fds events and other non-BLE hardware events (ADC, I2C, and such).

RE: calling fds_write within a ble_evt_handler gets the SD or app stuck

Andy — Mon, 22 Apr 2019 14:43:36 GMT

It sounds to me like you have a problem with your code. Executing blocking code in event handlers is not a good idea, you need to use flags or to schedule function calls to be executed in the main context.

My guess is that the interrupt priority of the FDS module is lower than the BLE priority in your code.