Circuitpython: SPI + Bluetooth crash nRF52840

[urish]

Calling the write() method of an SPI object while Bluetooth is active crashes the firmware.

Here is a minimal code that reproduces the issue:

import board
import busio
from ubluepy import Peripheral

p = Peripheral()
p.advertise()

spi = busio.SPI(board.P0_22, MOSI=board.P1_00)
while not spi.try_lock():
    pass
spi.write(bytes([0xff]))

If you comment out the last line (the call to spi.write()), then it doesn't crash anymore. Tested on the nRF52840 USB Dongle.

[jerryneedell]

FYI - I can reproduce this on my nrf52840_dongle but it does not fail on a feather_nrf52832

[jerryneedell]

A bit more information -- I was able to successfully mount my SDCard -- SPI device -- and then initiate a BLE advertisement and it runs OK - however if I then access the SDCard the system resets as above.

These tests were don an a PCA10056 nRF52840-DK - confirms that the issue occurs on both the Dongle and the DK.

[urish]

I am observing the same as @jerryneedell

[urish]

Positive outcome from this issue - a blog post describing how to optimize the performance of CircuitPython code:

https://medium.com/@urish/embedded-python-cranking-performance-knob-up-to-eleven-df31a5940a63

[dhalbert]

I spent some time on this, but didn't discover the root cause. I tried other pins, including ones that are marked as definitely safe for high-speed I/O. It seems like there's a reset when the SPI write is attempted. Nothing appears on the SPI pins.

[jerryneedell]

Since it does not occur on the nrf52832, It could be related to the s140 SD or something in the nrf52840 code. Both are differences.

[jerryneedell]

just for fun - I tried accessing an I2C device while BLE was active on a PCA10059 Dongle and it worked fine.

[dhalbert]

I also tried I2C, and also UART, and neither caused a problem. It seems to be SPI in particular. I looked at the code and I don't see anything obvious. I changed the HardFault_Handler() to hang (as it does in atmel-samd) instead of just returning and maybe I can catch the problem. Will report back.

The SoftDevice documentation describes how it reserves a few peripherals for its own use (like TIMER0) or provides only a restricted API to a shared peripheral, but I don't see any conflicts.

[dhalbert]

This BLE + SPIM crash sounds quite similar to this issue: https://devzone.nordicsemi.com/f/nordic-q-a/33982/sdk-15-software-crash-during-spi-session/130572. I'm inquiring.

[jerryneedell]

Not the most encouraging response to your inquiry :-(

[arturo182]

Have you tried building a DEBUG build, it has asserts enabled, maybe that helps.

[jerryneedell]

I disabled SPIM3 in nrfx_config.h and the problem seems to have been resolved. I can now run a blue advertise and then mount my SPI SD Card

diff --git a/ports/nrf/nrfx_config.h b/ports/nrf/nrfx_config.h
index f217cb053..a9bee8912 100644
--- a/ports/nrf/nrfx_config.h
+++ b/ports/nrf/nrfx_config.h
@@ -27,9 +27,9 @@

 // Enable SPIM2 and SPIM3 (if available)
 #define NRFX_SPIM2_ENABLED 1
-#ifdef NRF52840_XXAA
-    #define NRFX_SPIM3_ENABLED 1
-#endif
+//#ifdef NRF52840_XXAA
+//    #define NRFX_SPIM3_ENABLED 1
+//#endif

[tannewt]

Can we close this?

[dhalbert]

Right now we’re not using SPIM3, which is only a workaround. Still to re-test and debug the primary problem.

[tannewt]

Ok, I'm moving to 4.x. We don't need it for 4.0.0

[dhalbert]

Fine to defer!

[dhalbert]

@hathach has gotten SPIM3 to work with BLE in use on Arduino, so this should be retested, trying to duplicate those conditions.

[dhalbert]

Just found this in the nRF SDK release notes for v15.3.0:

The workaround for Anomaly 198 for nRF52840 SPIM3 peripheral that has been implemented in nrfx_spim cannot be used with a SoftDevice.
Flag NRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED must be set to zero.
The workaround based on a dedicated RAM block for SPIM3 must be used instead.

See https://devzone.nordicsemi.com/f/nordic-q-a/33982/sdk-15-software-crash-during-spi-session/216253#216253

[hathach]

a RAM block according to interconnect diagram is probably a 8KB of RAMx. We can allocated a fixed 8KB of RAM7 just for SPIM3 in linker script. It is a pain and a wasteful walkaround, but driving LCD 4x faster is more fun to the user I guess.

Update: correct the memory layout for 52840