SPI + sd_app_evt_wait and nested interrupts?!

[Alex Co]

sdk15, SES, SD132

Hi
I am using an SPI slave with nrf52 (master)

I launch in the main() and I also initialize the SPI slave on main.
I also configured an app timer and when it fires I read the SPI slave using nrf_drv_spi_transfer (burst read) for 9 bytes.
and then I wait for the spi transfer like this:

while (!spi_xfer_done)
{

    uint32_t err_code = sd_app_evt_wait();
    printf("SPI status=> %d count %d\r\n", err_code,count);
}

The problem is that the loop never ends. It seems that it is an interrupt nesting issue.
Can anyone tell me if it could be an interrupt nesting problem and if so how can I solve the problem?

Thanks

Alex

[Jørgen Holmefjord]

Hi,

Are your app_timer running at higher or equal priority to the SPI? If it does, the SPI IRQ handler will be blocked by the interrupt you are already in. You may also face issues if you do softdevice calls from high priority interrupt context.

In general, it is not recommended to stay long in interrupts, like doing blocking calls. If you set a flag in the handler and start the transfer in the main context, that will normally be a much safer solution.

Best regards,
Jørgen

[Jørgen Holmefjord]

Priorities are typically configured in the sdk_config.h file:

• APP_TIMER_CONFIG_IRQ_PRIORITY
• SPI_DEFAULT_CONFIG_IRQ_PRIORITY

App_scheduler can be used to schedule transfers that are processed in main context, yes. 

The priority scheme is built into the ARM Cortex M4 CPU, and is used for interrupts from most hardware peripherals, in addition to our softdevices. You can see the available priorities for application in softdevice specifications.

We have FreeRTOS support in the SDK, but the interrupts from the hardware peripherals and softdevice will still be running with the priorities from the CPU.

[Alex Co]

By just decreasing the priority of the app_timer (now level 7) and keeping spi priority (level 6) it works now.

(But I am going now to move also the processing into app domain)

Thank you very much!