nRF52840 SPI3 data corruption at 16 Mhz - anomaly workaround included

[Sam-IIT]

citing the following issues

 Nrf 52840 SPIM3 slew rate issue at 16 Mhz   RE: nRF52840 BLE causing display glitch on GC9A01 using SPIM 

 SPIM3 tx data corruption, byte carried over from previous operation. 

I've been able to implement the 16 Mhz on the SPIM3. However, the incoming data on the MISO is still corrupted. With my oscilloscope I can see the incoming data is correct. 

I've implemented the CONFIG_NRF52_ANOMALY_198_WORKAROUND in my proj.conf, even thought this config is now enabled by default in the Connect SDK. 

The solution proposed in  RE: nRF52840 BLE causing display glitch on GC9A01 using SPIM is not really clear to me and touching files in the build folder is not ideal. 

Is there any extra anomaly that I might be missing and/or configuration of the SPI3 for speed above 8 Mhz? 

[EDIT]

Apparently the incoming data is shifted by 1 bit to the RIGHT. As I wrote before, is correctly detected by my oscilloscope, but once in the nRF it gets shifted.
This is still an issue since I cannot state the value of the missing right-most bit. CPOL and CPHA are correct by the datasheet on the interfaced device.

[Simonr]

Hi

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

[Sam-IIT]

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!

[Simonr]

Hi

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

[Sam-IIT]

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.

[Edvin]

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