What are the performance implications of using SPIM on the nRF52832 with anomaly-58-workaround?

RE: What are the performance implications of using SPIM on the nRF52832 with anomaly-58-workaround?

Anthony W — Fri, 21 Jun 2024 12:15:42 GMT

Got it, thank you for the clarification!

RE: What are the performance implications of using SPIM on the nRF52832 with anomaly-58-workaround?

Einar Thorsrud — Fri, 21 Jun 2024 10:29:58 GMT

Hi,

The workaround does not work by using the SPI peripheral. Instead, it use GPIOTE via PPI to stop the SPI transaction by triggering the STOP task of the SPIM (you can see this in the implementation of anomaly_58_workaround_setup() if you are interested in the details).

If you have an available PPI and GPIOTE channel that is never used outside of this driver, the workaround shoudl be effective without significant side effects and this will be handled automatically as long as the workarond is enabled.

RE: What are the performance implications of using SPIM on the nRF52832 with anomaly-58-workaround?

Anthony W — Thu, 20 Jun 2024 17:44:03 GMT

Interesting, I didn't think I had any single byte transactions, but after setting up SPI most of the communication is handled by the vendor's driver library, so the must use single transactions for some part of it.

Transactions happen frequently (up to 500Hz) but they are relatively small (around 4 - 40 bytes, depending on the packet type). So maybe DMA isn't helping here anyway, I can investigate that (like I mentioned, I didn't really notice any performance change).

But one thing I wanted to clarify, just so I know, is specifically the behavior of the workaround. Is it correct that, for 1 byte messages, it will use SPI without EasyDMA, and for 2 or more bytes it will use DMA? So the main overhead is just a little bit of extra logic to check the message size? My use case may or may not benefit from the DMA (all incoming messages are 4+ bytes, but perhaps there are single byte messages being transmitted as well) but I can investigate that further if it becomes a problem.

RE: What are the performance implications of using SPIM on the nRF52832 with anomaly-58-workaround?

Einar Thorsrud — Mon, 17 Jun 2024 12:21:27 GMT

Hi,

[quote user=""]From the description here it sounded like it applied to read/write calls with a single byte, but it seems to apply to calls with a single buffer, which is what I am using.[/quote]

The errata is only related to transmitting a single byte with SPIM (which is using DMA). A single buffer is no problem. If you never need to transmit a single byte you can ignore this. Transmitting more than 1 byte does not trigger the errata.

[quote user=""]So I'm wondering: is there any benefit to using SPIM in this case, or does the single buffer case just fall back to using SPI without EasyDMA?[/quote]

If you have transactions more than 1 byte, using DMA is more efficient as the CPU is only involved in setting up the transaction (and checking evenets once it has completed). Usng the SPI peripheral without DMA means that the CPU is involved for every byte. Depending on how much else your application is doing and the priorities this may or may not be a problem.

[quote user=""]so I'm wondering if I'm actually just causing the MCU to work more rather than less by enabling SPIM. But I'm not sure exactly what the workaround does.[/quote]

The workaround is only used when tramsitting a single byte, and it requiers some configuration on the users part when switching between single an multi byte transfers (I suggest reading the comments in spi_nrfx_spim.c for details). A central question here is how you use the SPI interface (number of transactions of different lengths). If you for instance never have 1 byte transactions, you can ignore this whole thing. If you mostly have short transactions, you don't gain that much from DMA anyway. If the transactions can be both short (and signle byte) and long, it is less obvious which is most efficient in your case.