Last byte of SPI transfer sometimes ends up in next transfer

RE: Last byte of SPI transfer sometimes ends up in next transfer

hmolesworth — Sat, 29 Jul 2023 01:47:53 GMT

If the sensor is something like the AD7785 AFE which uses single byte transfers note it can be used in multi-byte multiple register transfer mode; see this post which I gave an example on nrf52832-errata-58-spim-fix

RE: Last byte of SPI transfer sometimes ends up in next transfer

swo_w — Wed, 26 Jul 2023 13:36:44 GMT

I wish I could use a single transaction, the used sensor does not allow this.

For some reason I missed this post NRF52840 SPIM3 output wrong data with a very similar problem. My query was probably too specific. I yet have to find out how to use the work-arounds in Zephyr, but I'll look into that. It probably does explain why using global or static buffers "fixed" my issue. I'll try the workaround for SPIM3 or move to another SPIM.

RE: Last byte of SPI transfer sometimes ends up in next transfer

hmolesworth — Wed, 26 Jul 2023 10:46:40 GMT

For (mostly) adjacent registers I would recommend a single block SPI transaction to read all registers at once instead of multiple single-byte transactions even if that requires a couple of extra bytes as the status register is not adjacent to xyz; this reduces significantly the software overhead. Running SPIM3 at 32MHz is always a challenge, as SPIM3 has the lowest priority of all the peripheral devices (I kid you not) and latencies begin to be significant. You might find my comments towards the end of this post helpful: spim3-peripheral-not-reliable

RE: Last byte of SPI transfer sometimes ends up in next transfer

Simonr — Tue, 25 Jul 2023 13:40:01 GMT

Due to the summer vacation period we are currently understaffed, so delayed replies must be expected. I am sorry about any inconvenience this might cause.

One of my colleagues will get back to you (hopefully shortly). Thank you for your patience.

Simon