SPI Slave interrupt by the Bluetooth

RE: SPI Slave interrupt by the Bluetooth

Susheel Nuguru — Mon, 14 Dec 2020 07:38:00 GMT

[quote user=""]

I think it might be the issue similar to this post:

https://devzone.nordicsemi.com/f/nordic-q-a/4034/spi-slave-with-heavy-interrupt-in-btle#post-id-17712

[/quote]

This very much sounds like the issue mentioned in the link. We have to understand that this is a single core chip with the softdevice taking the highest priority with the CPU. And once the CPU has the SPIS semaphore there is little we can do on the slave side to get that semaphore back in time.

One of the problems seems to be the connection interval of your BLE connection. The softdevice might steal the CPU too often if you have very low number set for the connection perameters. Try increasing the connection interval if you are not targetting the throughput.

Change the SPIS_DEFAULT_CONFIG_IRQ_PRIORITY to 2 to give the SPIS handling a higher priority than the BLE host processing. This will increase the likelihood of the SPI owning the semaphore when the master is transmitting (increases the chances but not 100% guarenteed)

You can also tell the SPIM to retransmit the packet, when the slave responds with DEF character (happens when slave has to ignore packet sent by master as slave does not own the spi semaphore at that time)

RE: SPI Slave interrupt by the Bluetooth

dayizhang — Fri, 11 Dec 2020 11:45:26 GMT

I tried storing spi receive data into fifo and call m_ble_send in the main loop. But it doesnt help 😞. I found the problem became worse when my ble central (another 52840 chip) connected the first device and scanning for the second device. It backs to the normal problem behavior after both devices connected.

RE: SPI Slave interrupt by the Bluetooth

hmolesworth — Tue, 01 Dec 2020 22:39:07 GMT

I cant trigger my scope without single stepping

Try increasing the 'scope io pin drive to H0H1 in case the probes are very capacitive; it would have to be a very slow 'scope not to catch that toggle (must set Trig to Normal). Adding a second pin to the 'scope (also H0H1) which is driven on the packet corrupted condition might provide some useful information.

RE: SPI Slave interrupt by the Bluetooth

dayizhang — Tue, 01 Dec 2020 22:19:47 GMT

I understand. But I scoped the gpio line which toggling at the entrance and exit of spi handler. I cant trigger my scope without single stepping, which suggests the time is very very short. Much less than 1 ms.

RE: SPI Slave interrupt by the Bluetooth

hmolesworth — Tue, 01 Dec 2020 21:41:09 GMT

Perhaps I was too vague and quick to answer; this is a typical invocation of ble_nus_data_send():

    do
    {
       uint16_t length = (uint16_t)index;
       err_code = ble_nus_data_send(&m_nus, data_array, &length, m_conn_handle);
       // Also now check BLE_ERROR_GATTS_SYS_ATTR_MISSING or correctly set up due to timer race hazard
       if ((err_code != NRF_ERROR_INVALID_STATE)
        && (err_code != NRF_ERROR_RESOURCES)
        && (err_code != NRF_ERROR_NOT_FOUND)
        && (err_code != BLE_ERROR_GATTS_SYS_ATTR_MISSING))
       {
          APP_ERROR_CHECK(err_code);
       }
    } while (err_code == NRF_ERROR_RESOURCES);

This effectively blocks within an interrupt, which is to be discouraged. Blocking in the foreground is fine. The master may be sending the next SPI packet while the previous SPI interrupt is still active; simple to test, maybe it'll help. Buffering (copying) the received data might also help, hard to say without sight of the SPI handler

RE: SPI Slave interrupt by the Bluetooth

dayizhang — Tue, 01 Dec 2020 21:13:49 GMT

I thought ble_nus_data_send() just moves the packet into the bluetooth stack and softdevice handles the actual bluetooth communication at the background. So the conflict is the interrupts from softdevice and spi.

RE: SPI Slave interrupt by the Bluetooth

hmolesworth — Tue, 01 Dec 2020 20:45:51 GMT

Nested interrupts are often the issue; try moving ble_nus_data_send() out of the SPIS event handler and into foreground code such as main(). Set a bool flag in the SPIS event handler and when seen as set in the foreground then invoke ble_nus_data_send()