SPI Slave interrupt by the Bluetooth

[dayizhang]

Hi. I am using nrf52840 with Softdevice 16.0.0 + BLE_uart_peripheral.

The SPI master transmits 2 SPI packets every 10 ms. At the the SPIS event handler, I call ble_nus_data_send() to send the SPI packet out.

However, I found the first couple bytes of the second packet are quite often be zero or lost. But as far as I disconnected the bluetooth to the central, the packets are fine.

I put a GPIO lines before and after the ble_nus_data_send() to tell the master hold the spi transmission but the problem still there.

However, I found if I added 1 ms between the spi cs line low and start the first byte, and also 1 ms after cs line goes high, the chances to get a corrupted spi packet is significantly reduced.

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

I preferred the GPIO solution mentioned in the post rather than the time delay. 

Could you help to the GPIO in the right position?

[dayizhang]

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. 

[Susheel Nuguru]

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

 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)