NRF52840/FreeRTOS unable to sleep after using QSPI peripheral

RE: NRF52840/FreeRTOS unable to sleep after using QSPI peripheral

Susheel Nuguru — Mon, 16 Dec 2019 14:19:53 GMT

I was hoping to get your stripped project, since I suspect read_flash() activity is the one that mainly contributes to exercise this bug. Can you provide me a stripped project when you have time?

RE: NRF52840/FreeRTOS unable to sleep after using QSPI peripheral

Jon — Mon, 16 Dec 2019 14:14:14 GMT

Understood. If there's more that I can provide (e.g. SPI traces, etc. please let me know)

RE: NRF52840/FreeRTOS unable to sleep after using QSPI peripheral

Susheel Nuguru — Mon, 16 Dec 2019 13:46:32 GMT

I used your code snippet to replicate the bug, but I could not, so it must be the transaction on QSPI that matters and influences the behavior.

To create an internal ticket, I need to reproduce this bug, so that I give the developers enough information to reproduce it.

On the other side, it seems that you have a workaround to continue on your work.

RE: NRF52840/FreeRTOS unable to sleep after using QSPI peripheral

Jon — Wed, 11 Dec 2019 14:18:31 GMT

Also note that even after calling uninit the isr is still pending, so I am currently calling uninit and then following the uninit call with the NVIC-clearpendingirq call.

Also, I found that this stick interrupt send to depend on whether I make a call to nrfx_qspi_mem_busy_check(). I tried different the qspi driver code but was a bit confused at some of the places it was enabling interrupts.

Jon

RE: NRF52840/FreeRTOS unable to sleep after using QSPI peripheral

Susheel Nuguru — Wed, 11 Dec 2019 12:00:08 GMT

That sounds like a bug in QSPI driver.

Normally you do not need to call nrfx_qspi_uninit to have the pending bit cleared, the driver should have first handled the interrupt before disabling it.

Your workaround to clear the pending bit of NVIC for QSPI just before going sleep sounds promising, but I am still a bit worried as to why the QSPI driver became idle by disabling the NVIC->QSPI related interrupt and not disabled the event generation of this interrupt.