nRF52840 SPI3 data corruption at 16 Mhz - anomaly workaround included

RE: nRF52840 SPI3 data corruption at 16 Mhz - anomaly workaround included

Sam-IIT — Wed, 03 Sep 2025 08:57:17 GMT

we are designing the integrated board for our solutions, so I'll be able to test this at some point at the end of the year. I thank you all for your time and help. I'll try to remember to come back with some results!

all the best

Sam

RE: nRF52840 SPI3 data corruption at 16 Mhz - anomaly workaround included

hmolesworth — Tue, 02 Sep 2025 22:17:55 GMT

Bit-shift is likely due to hardware timing issues, very different to byte-corruption due to SPIM3 anomaly issues.

"Standard four-wire 32-bit SPI interface with CMOS or low-voltage differential signaling (LVDS) I/O pins". If using LVDS_en tied high a 100R termination resistor is required on the digital inputs to the RHS2116 and the differential receive circuit on MISO may be adding a delay. If LVDS_en is tied low is there a single-ended buffer in the MISO path contributing to phase delay?

In both cases connection wires or traces above 1 or 2 inch should be suspect. Test effect of connection wires or traces by doubling or tripling the connection length of SCLK, MOSI and MISO and see if a further bit shift to the right occurs. If possible test with a connection length of 1 inch or less and see if the bit shift disappears. Yes, not so easy ..

RE: nRF52840 SPI3 data corruption at 16 Mhz - anomaly workaround included

Sam-IIT — Tue, 02 Sep 2025 09:25:27 GMT

Hi Edvin,

thank you for your response. I have no issue with other SPIs and everything works fine at 8 Mhz. Right now I just implemented a workaround that shift the data and drop the comparison for the LSB bit. Could this be related to cable length and similar issues?

The SPI3 is connected to a RHS2116 intan device and uses the nrfx interface.

RE: nRF52840 SPI3 data corruption at 16 Mhz - anomaly workaround included

Edvin — Mon, 01 Sep 2025 12:32:24 GMT

Hello,

Simon is out of office for a while.

It is difficult to test without the sensor that you are using.

1: Does the device work if you turn down the SPI3 speed?

2: Does it work if you turn down the speed, and change to another SPI instance (0, 1 or 2)?

Best regards,
Edvin

RE: nRF52840 SPI3 data corruption at 16 Mhz - anomaly workaround included

Sam-IIT — Tue, 26 Aug 2025 13:43:28 GMT

Hi Simon, I tried as you suggested swapping NRF_DRIVE_H0H1 for NRF_DRIVE_E0_E1 but then the MISO data showed only 0's on reception.

RE: nRF52840 SPI3 data corruption at 16 Mhz - anomaly workaround included

Simonr — Tue, 26 Aug 2025 12:40:42 GMT

I wonder if you need to set the drive mode to extra high here. NRF_DRIVE_E0E1 to enable the highest throughput possible. Let me know if that doesn't pan out and I'll have a closer look at what's going on here. I agree that erratum 174 should not apply here.

Best regards,

Simon

RE: nRF52840 SPI3 data corruption at 16 Mhz - anomaly workaround included

Sam-IIT — Fri, 22 Aug 2025 09:31:29 GMT

Hi Simon,

thanks for your message. I'm using the SDK 3.0.2 and this is my overlay file with the pin I used.

&pinctrl {
	spi3_default {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 0, 21)>,
			        <NRF_PSEL(SPIM_MOSI, 0, 15)>,
			        <NRF_PSEL(SPIM_MISO, 0, 17)>;
					nordic,drive-mode = <NRF_DRIVE_H0H1>;
		};
	};

	spi3_sleep {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 0, 21)>,
			        <NRF_PSEL(SPIM_MOSI, 0, 15)>,
			        <NRF_PSEL(SPIM_MISO, 0, 17)>;
			low-power-enable;
			nordic,drive-mode = <NRF_DRIVE_H0H1>;
		};
	};
};

my_spi: &spi3 {
	compatible = "nordic,nrf-spim";
	status = "okay";
	pinctrl-0 = <&spi3_default>;
	pinctrl-1 = <&spi3_sleep>;
	pinctrl-names = "default", "sleep";
	max-frequency = <DT_FREQ_M(16)>;
	cs-gpios = <&gpio0 19 GPIO_ACTIVE_LOW>;
};

I'm using those pin specifically to exploit the fast GPIOs. I did cut the SB10-15 bridges and soldered the SB20-25, everything works at 8 Mhz.

I have enabled CONFIG_NRF52_ANOMALY_198_WORKAROUND for the 198. For 193 and 195 I'm not disabling the SPIM3 in my code. For the 174 I'm actually using the NRFX_SPIM_FLAG_NO_XFER_EVT_HANDLER flag on nrfx_spim_xfer, so I don't think this should apply, am I correct?

thank you!

RE: nRF52840 SPI3 data corruption at 16 Mhz - anomaly workaround included

Simonr — Fri, 22 Aug 2025 09:17:23 GMT

First off, what pins are you using for SPI communication in your application? And what version of the nRF Connect SDK are you working on?

There are a total of four errata related to SPIM3, so make sure they're all addressed in your application. Numbers are 174, 193, 195 and 198.

Best regards,

Simon