nRF52840 SPI3 data corruption at 16 Mhz - anomaly workaround included

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.
Parents
  • 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

  • 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!

Reply
  • 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!

Children
No Data
Related