spi slave race condition

[Matej]

Hi!

After reading few posts about spi slave/master issues... I'm also challenging with one of them. I have following setup nrf51822, s130 2.0.1 and sdk 12.3.0… nrf51 (spi slave) is communicating with arm cortex m3 (spi master) and I have established connection with smart device and I also run sd_ble_gap_scan_start and forward founded devices to main mcu. Main mcu process founded devices and sends them to several interfaces and also back to nrf – which sends founded devices to smart device as notifications.

Then I perform some of stress tests and everything works fine, until I set scan parameter over 50% of radio usage (e.g. scan intv. 200ms, window 110ms) and there is a lot of broadcasters.

In spi connection I use clk, miso, mosi, csn and additional irq line (indicating that main mcu should read out the data), which gets to high level on NRF_DRV_SPIS_BUFFERS_SET_DONE. For setting SPI buffers I’m using nrf_drv_spis_buffers_set function.

But, meanwhile setting spi buffers (irq line is still low), main mcu sends some data and in most cases buffers are set ok (and it's handeld as full duplex communication), but in some cases I get just half of packet and I never get another half of packet and also processing device found event fails...

Currently I’m using default spis default configuration – that means that irq priority is 3. But after reading some posts I somehow conclude that if I set priority to highest can happen that Softdevice could start "starving"…

Any suggestions? Adding additional mutex somewhere? Any similar issues?

Thank you for info!

BR, Matej

[Sigurd]

Hi,

You can use APP_PRIORITY_HIGH(irq priority 1 on nRF51) as long as

1. You are not making any SoftDevice calls from the high priority context.
2. The callback is short so that it is not blocking UPPER STACK from executing.

If you have APP_PRIORITY_HIGH in the SPI driver and have a lot of traffic with it, then you MIGHT notice lower throughput in the BLE stack because your SPI driver is blocking upper stack. It wont cause any faults and it is legal to use but you might see lower throughput. If that is not a problem in your usecase, and if you see that it solves your issues with SPI, it should be fine to use.