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

[Anthony W]

I am communicating with a sensor via SPIM. Without enabling `anomaly-58-workaround` I see numerous errors indicating

<wrn> spi_nrfx_spim: Transaction aborted since it would trigger nRF52832 PAN 58

All the read and write events happen with single buffers. 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.

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? I didn't notice any performance changes switching between the two, 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.

[Einar Thorsrud]

Hi,

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.

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.

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?

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.

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.

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.