nRF52840 QSPI driver callback eventually not being called after reading data from the flash memory continuously

[Tosa]

I am using the nRF52840 (with SDKv17.0.0 + s140_7.0.1) and made a custom FW based on the ble_app_hrs example. My HW has a 64MB NOR flash memory chip and eventually I want to add USB MSC to pull the data off it, but until I get that working, I want to read and stream the stored data via BLE.

The data is stored as continuous data starting at address 0 can be large (MB) and I want to stream the data as fast as possible over BLE. I am using short BLE connection intervals (8.5ms is supported by my central device) and a repeating one-shot 20ms timer which, when expired, causes a page read (256B) from flash memory and twelve 20B packets sent to the BLE stack (the remaining bytes of the 256B read are buffered until the next timer expiration). Since two connection intervals occur within 20ms, twelve packets are sent over the stack before the next timer expiration. I also have a queue to hold packets that are not sent due to NRF_ERROR_RESOURCES errors and I use BLE_GATTS_EVT_HVN_TX_COMPLETE to clear out this queue as needed. I've confirmed that there is no issue with this setup. This repeats until all data is read from flash memory.

The issue that I'm running into is that as the data is reading + streaming, eventually the QSPI driver stops issuing its callback and my flash memory read function is blocked and never continues. I tried using a flag instead of blocking, and similarly the flag also doesn't get cleared, so my "finish read" function never fires. I tried an experiment which ignores the callback uses a 1ms timer that starts when nrf_drv_qspi_read() is called. Upon expiration of the timer my "finish read" function fires normally and I continue with the process as noted above . Thus it seems to be an issue with the QSPI driver. Please advise, as soon I will move to USB MSC and need to ensure that my QSPI implementation is robust.

[Kenneth]

Sorry, don't see any way this may occur. 

I would have looked at the interrupt priorities between BLE, QSPI and app_timer(?). Maybe there is a corner case where one block the other somehow. Also, can you try to make the 20ms timer 'repeated' instead of 'one-shot'? You can use flags instead in the timeout handler to check if it should read data or not. Reason for trying: I have seen corner cases in the past that one-shot timers may be problematic (indirectly depend on other timers that may be running), but I was under the impression these have been resolved.

Kenneth

[Tosa]

I tried a continuous app_timer and it made no difference. The app_timer and QSPI interrupt priorities are both 6 and the BLE interrupt priorities are untouched from whatever is default (based on the HRS example project).

The issue seems to be caused by sending 12-13 packets every 20ms to the BLE stack (and queuing the ones that trigger NRF_ERROR_RESOURCES). Per the debugger, the program is stuck at WAIT_FOR_FLASHMEM (and eventually goes to app_error_fault_handler() -> NRF_BREAKPOINT_COND;). If I throttle the loop that sends the 12-23 packets per QSPI read, then the program does not get stuck. This obviously slows down the file transfer. If I go back to my 1ms timer experiment work-around, I can ignore the QSPI callback and have a faster file transfer. The 256B read finishes in <150us (using 16MHz fast read) so there is enough guard band with a 1ms timer (and I don't think that app_timer can have <1ms intervals, correct?). Does this seem like the cause of the issue and a reasonable solution?

[Kenneth]

It's seems like a reasonable solution, and the app_timer can't be <1ms no.

Kenneth