This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf_fstorage_sd not receiving SOC events

Hi,

I'm developing an application for nrf52840 that's essentially based on both the USB MSC example and the BLE NUS example in SDK 14. I started with the USB MSC example, wrote a block device driver so I could put the filesystem in internal flash, and using raw NVMC calls to write/erase, this all worked fine. When I integrated the SoftDevice and BLE functionality for NUS, I switched the block device to using nrf_fstorage because it seemed it would be easier to let the SDK code coordinate flash access with the SoftDevice than to do it myself.

Ok, so the problem I'm having is at some point after USB MSC is started the host issues an erase command, the block device driver calls into fstorage to erase, the erase command is accepted, but I never see the SOC event signalling the erase was completed. My handler that I registered with nrf_fstorage doesn't get called, and even nrf_fstorage_sys_evt_handler() doesn't get called. However, using JTAG I can verify the flash region that was requested to be erased actually does get erased.

So the question is, why aren't I getting the SOC event? Is it maybe firing but somehow fstorage isn't seeing it? Can I get any lower visibility into the dispatching of SOC events?

Update 1 2017-09-07:

Looking into nrf_sdh_soc and nrf_sdh, if I put a breakpoint in nrf_sdh_soc_evts_poll() I see that never gets hit. Seeing that nrf_sdh_soc_evts_poll() gets called from nrf_sdh_evts_poll(), which is in turn called from SD_EVT_IRQHandler() I placed a breakpoint there, and it seems the SoftDevice event interrupt isn't firing even though the erase is being completed.

Update 2 2017-09-07:

I think maybe I've found the problem. After calling nrf_fstorage_erase() my code busy waits on a flag set by my SOC event handler, which is where it is stalling. If I stop execution and check the call stack, I see I am in state_date_handle_out(), called from the switch statement in endpoint_out_event_handler(). The function call is in a critical region! So of course the SoftDevice interrupt isn't firing.

Related