BLE radio interrupts interfering with SPI

RE: BLE radio interrupts interfering with SPI

hmolesworth — Sat, 11 Apr 2026 18:29:31 GMT

For best performance maybe try SPIM1, since SPIM1 eclipses the RADIO, UART and SAADC:

// Bus master nRF52840
// =======================
// CPU
// CTRL-AP
// USB
// CRYPTOCELL
// SPIM1/SPIS1/TWIM1/TWIS1  Same priority and mutually exclusive
// RADIO
// CCM/ECB/AAR              Same priority and mutually exclusive
// SAADC
// UARTE0
// SPIM0/SPIS0/TWIM0/TWIS0  Same priority and mutually exclusive
// SPIM2/SPIS2              Same priority and mutually exclusive
// NFCT
// I2S
// PDM
// PWM0
// PWM1
// PWM2
// QSPI
// PWM3
// UARTE1
// SPIM3

RE: BLE radio interrupts interfering with SPI

Andrew Mowry — Fri, 10 Apr 2026 16:36:03 GMT

After more testing it does seem like SPIM2 is considerably more reliable, so I'm just going to switch to that for now.

RE: BLE radio interrupts interfering with SPI

Andrew Mowry — Thu, 09 Apr 2026 23:15:40 GMT

Okay, thanks again. I'll look into this.

RE: BLE radio interrupts interfering with SPI

hmolesworth — Thu, 09 Apr 2026 22:09:21 GMT

Yes, quite so; this issue affects all nRF52840 peripherals, and when multiple peripheral's DMA bus Masters are actively competing for a particular AHB RAM bus the peripheral priority order dictates those least affected. SPIM3 happens to be the worst, but BLE Radio DMA and CPU memory access eclipse all the SPIMs. The true test to indicate if this is the problem at hand is to enforce SPIM DMA buffers in isolated RAM sections, easy to do but compiler-dependent syntax. Verify linker success in isolating the DMA buffer memory addresses by examining the linker map before testing.

One method is to simply reserve an entire RAM block and align on the RAM boundary so nothing other than the CPU can access, preferably between DMA transfers which implies double-buffering if not; doesn't matter which RAM segment is used:

uint8_t Spim3BufferTx[8192] __attribute__((section(".bss"), aligned(0x2000), used));
uint8_t Spim3BufferRx[8192] __attribute__((section(".bss"), aligned(0x2000), used));
struct spi_buf *pSpiBufferTx = Spim3BufferTx;

RE: BLE radio interrupts interfering with SPI

Andrew Mowry — Thu, 09 Apr 2026 21:01:09 GMT

Thanks for your help. Would the stall occur with SPIM2 as well or this issue only related to SPIM3? In my tests the SPIM2 behavior seems very similar.

RE: BLE radio interrupts interfering with SPI

hmolesworth — Thu, 09 Apr 2026 19:33:45 GMT

You are likely seeing an AHB bus stall caused by the BLE code/peripherals tying up the AHB bus when the SPIM is looking to transfer data. This can be avoided by placing SPIM buffers in separate Slave AHB areas by reserving RAM segments for those buffers. I wrote some details on how to do this which are applicable on the nRF52840 stallstat-on-spim3

The stall is detectable on SPIM3 only, not SPIM0/1/2, though I'm not sure how reliable the detection is; clearing might require writing a '1' to the register, I forget now. Worth incrementing a counter on each occurrence to verify stall detection. The stall mechanism on SPIM3 is supposed to hold the SPIM3 SCK until the bus is available, but I'm not sure if this actually works.

"6.25.6.13 STALLSTAT Address offset: 0x400
Stall status for EasyDMA RAM accesses. The fields in this register are set to STALL by hardware whenever a stall occurs and can be cleared (set to NOSTALL) by the CPU."

Edit: Also note SPIM3 has the lowest bus priority of all, which is not helpful! See spim3-peripheral-not-reliable and maybe also look at adc-infuriating-behaviour and start-pwms-synchronous

RE: BLE radio interrupts interfering with SPI

Andrew Mowry — Thu, 09 Apr 2026 15:45:20 GMT

If it's helpful, I'm using P0_15 for MOSI, P0_20 for MISO, and P0_13 for SCK, and P1_02 for SS. I believe that MOSI and SCK are set to high drive by the Adafruit NRF board package that I'm using.