nRF52840 SPI MISO is actively driven

[Dave Littell]

Greetings,

Using SDK v3.1.1 the SPI MISO signal appears to be actively driven by the nRF5280 for both my SPI1 and SPI2 configurations.  In both cases there are no active SPI Slaves connected - just a loopback connection from MOSI to MISO.  A SPI Master should NEVER drive MISO, only pull it down for when CS is negated.  I suspect there's some magic pin configuration somewhere that's missing in the devicetree but I can't find anything.  I read some other questions regarding this same problem that suggested a MISO pin should be explicitly configured as a GPIO input but that doesn't work either.

Here's my overlay portions for SPI1:

&spi1 {

    compatible = "nordic,nrf-spim";

    status = "okay";

    pinctrl-0 = <&spi1_default>;

    pinctrl-1 = <&spi1_sleep>;

    pinctrl-names = "default", "sleep";

    easydma-maxcnt-bits = <16>;

    cs-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>, <&gpio0 11 GPIO_ACTIVE_LOW>;

    module_nvm: module_nvm@0 {

        compatible = "jedec,spi-nor";  /* TODO FIXME this needs to be set up for the module's non-volatile memory. */

        reg = < 0 >;

        spi-max-frequency = < 8000000 >;

        label = "MODULE_MEMORY";

    };

    module_rtc: module_rtc@1 {

        compatible = "jedec,spi-nor";  /* TODO FIXME this needs to be set up for the module's RTC. */

        reg = < 0 >;

        spi-max-frequency = < 8000000 >;

        label = "MODULE_RTC";

    };

};

&pinctrl {

    spi1_default {

        group1 {

            psels = <NRF_PSEL(SPIM_SCK, 1, 8)>,

                    <NRF_PSEL(SPIM_MOSI, 1, 10)>;

        };

        group2 {

            psels = <NRF_PSEL(SPIM_MISO, 1, 9)>;

            bias-pull-down;

        };

    };

    spi1_sleep {

        group1 {

            psels = <NRF_PSEL(SPIM_SCK, 1, 8)>,

                    <NRF_PSEL(SPIM_MOSI, 1, 10)>;

        };

   

        group2 {

            psels = <NRF_PSEL(SPIM_MISO, 1, 9)>;

            bias-pull-down;

        };

    };

};

[Turbo J]

You have the "bias-pull-down" option enabled. The pullup and pulldown resistors in NRF chips are unusually strong (see PS), around 15K Ohms.

This won't look like an open line in the oscilloscope but more like an inverted I²C signal. And yes, those pulldowns are always active when you configure the bus pins this way.

[Dave Littell]

Thanks for the reply but 15K shouldn't be enough to defeat a loopback from MOSI, right?

[Turbo J]

Only when MOSI is actively driven in an SPI transaction.

I don't remember whether the MCU drives MOSI at all after SPI transactions.

[Håkon Alseth]

Hi,

 

nRF SPIM module does not drive the MISO, but you can enable a pull in the pad itself (pull-up/down of approx. 13 kOhm).

Dave Littell said:

Thanks for the reply but 15K shouldn't be enough to defeat a loopback from MOSI, right?

The loop-back should be able to drive such a load.

 

You have two cs-gpios defined, and two sensors, are these connected now? If yes, can you double-check the orientation of their cs-gpios to ensure that they are indeed idle when testing this loopback scenario?

 

Kind regards,

Håkon

[Dave Littell]

OP second sentence: "In both cases there are no active SPI Slaves connected - just a loopback connection from MOSI to MISO."

[Håkon Alseth]

Q1: Have you tried using other GPIOs than P1.08 to P1.10 ?

Q2: Have you tried to switch the MOSI to MISO (in firmware), to see if there is any other pin conflict that could explain why it does not sample?

Ie. if MOSI outputs on P1.10, and MISO does not sample correctly on P1.09;

will then MOSI output correctly on P1.09, and MISO sample correctly on P1.10?

Q3: What is being read by the nRF when you loopback? Please provide any runtime logs.

Q4: how did you measure that MISO is driven by the nRF? please share any details on your test setup.

 

Kind regards,

Håkon

[Dave Littell]

Thanks for your attention.  It turns out the board had some misbehaving SPI Slaves that were driving MISO in spite of their CS signals being negated.