Gen 3 SPI and SPI1 Threadsafe?

Do SPI and SPI1 share resources?

This question partly stems from the fact that the datasheets only indicate 1 SPI bus is available here, but then shows both SPI and SPI1 here and in deviceOS docs.

Do SPI and SPI1 share any firmware or hardware resources? I may want to run peripherals on each of the busses potentially in different threads (and maybe different than the main thread).

nRF52840 Specs & Docs

My research on the nRF52840 indicate that the 4 SPI busses are generally independent from each other and shouldn’t share resources. Per the nRF52840 datasheet:

6.24.1.2 Shared resources
The SPI shares registers and other resources with other peripherals that have the same ID as the SPI.
Therefore, the user must disable all peripherals that have the same ID as the SPI before the SPI can be
configured and used.
Disabling a peripheral that has the same ID as the SPI will not reset any of the registers that are shared
with the SPI. It is therefore important to configure all relevant SPI registers explicitly to secure that it
operates correctly.
See the Instantiation table in Instantiation on page 23 for details on peripherals and their IDs.

From the referenced table, all the peripheral IDs are different between the 4 SPI busses, and SPI and SPI1 only share IDs with TWI and TWI1, so from a hardware perspective as long as I’m not using those Two-Wire instances, there should be no shared hardware resources. So hardware seems good, but then there’s deviceOS.

deviceOS

A while back I had this thread where I had problems with the SPI bus hanging in multi-threaded operation due to SPI not being threadsafe. Supposedly this also affected gen 3, and according to @rickkas7 a fix was planned at that time. v1.5.0 lists bugfixes:

[wiring] Fixes a regression in SPI due to thread-safety additions from #1879 #2023
[Gen 3] Fixes concurrency/thread-safety SPI issues with Ethernet Featherwing #1879

These seem to address the prior specific issue, but my question is, can I safely use SPI and SPI1 simultaneously in separate threads from v1.5.0 onwards?. The github issue didn’t talk about much beyond the Ethernet Featherwing.

Yes, you can use SPI and SPI1 concurrently, as you always should have been able to do.

The main problem people ran into on Gen 3 was that SPI1 overlaps the pins used by the Ethernet Featherwing, so you can’t use Ethernet and SPI1 at the same time unless you remap the pins. And prior to 1.5.0, the mutex lock in SpiTransaction was broken, and when the system accessed Ethernet, it could conflict with user SPI access.

I see no reason why you can’t use SPI and SPI1 at the same time.

1 Like

Thanks! That was what I expected but wanted to double check before I start picking SPI parts instead of I2C for my CAN Bus and such. Always appreciate the depth of your knowledge. Saves us all much time and energy :smiley:

1 Like