Migrating to SDK 2.0.0 caused my CS pin to stop working on my SPI

[stevenminnick]

Was using SDK 1.9.1 up till now, but I migrated to SDK 2.0.0 and I changed my overlay file to add the pin control stuff.  I have a nrf5340 and use the app_ns board config.

This is the overlay file

&pinctrl {

    spi2_default: spi2_default {

        group1 {

            psels = <NRF_PSEL(SPIM_SCK, 0, 26)>,

                <NRF_PSEL(SPIM_MISO, 0, 10)>,

                <NRF_PSEL(SPIM_MOSI, 1, 5)>;

        };

    };

    spi2_sleep: spi2_sleep {

        group1 {

            psels = <NRF_PSEL(SPIM_SCK, 0, 26)>,

                <NRF_PSEL(SPIM_MISO, 0, 10)>,

                <NRF_PSEL(SPIM_MOSI, 1, 5)>;

            low-power-enable;

        };

    };

};

&spi2 {

    compatible = "nordic,nrf-spim";

    status = "okay";

    pinctrl-0 = <&spi2_default>;

    pinctrl-1 = <&spi2_sleep>;

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

    cs-gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;

};

This is a C file

static const struct device * spi_dev;

static struct spi_cs_control spi_cs = {

    .gpio_dev = NULL,

    .gpio_pin = 25,

    .gpio_dt_flags = GPIO_ACTIVE_LOW,

    .delay = 0,

  };

static struct spi_config spi_cfg = {

  .operation = SPI_WORD_SET(8) | SPI_TRANSFER_MSB,// |

        // SPI_MODE_CPOL | SPI_MODE_CPHA,

  .frequency = 8000000,

  .slave = 0,

  .cs = &spi_cs,

};

spi_dev = device_get_binding("SPI_2");

    int err;

    static uint8_t tx_buffer[3];

    static uint8_t rx_buffer[3];

    const struct spi_buf tx_buf = {

        .buf = tx_buffer,

        .len = sizeof(tx_buffer)

    };

    const struct spi_buf_set tx = {

        .buffers = &tx_buf,

        .count = 1

    };

    struct spi_buf rx_buf = {

        .buf = rx_buffer,

        .len = sizeof(rx_buffer),

    };

    const struct spi_buf_set rx = {

        .buffers = &rx_buf,

        .count = 1

    };

    tx_buffer[0] = 0x00;

    tx_buffer[1] = 0x80; // write

    rx_buffer[2] = 0x00;

err = spi_transceive(spi_dev, &spi_cfg, &tx, &rx);

So that code used to make the CS line work during communication.  The 1.9.1 overlay file used to look like this

&spi2 {
    compatible = "nordic,nrf-spim";
    status = "okay";
    sck-pin = <26>;
    mosi-pin = <37>;
    miso-pin = <10>;
    cs-gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
};

And I took away the pin config lines for the new pin control stuff. 

Any idea what I'm doing wrong or what I'm missing?  I watch the pins on a logic analyzer and the CS line gets configured and goes high and then never goes low. 

Also

I was looking through here

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.0/zephyr/hardware/peripherals/spi.html

 

And saw this

struct spi_cs_controlÁ

#include <spi.h>

SPI Chip Select control structure.

This can be used to control a CS line via a GPIO line, instead of using the controller inner CS logic.

 

So I can use the controller inner CS logic?  How do I do that?  Was I always using the GPIO line?  

[Albrecht Markus Schellenberger]

Hello Steven, 

So I can use the controller inner CS logic?  How do I do that?  Was I always using the GPIO line?  

Referring to the Pin control transition section in our Migration notes for nRF Connect SDK v2.0.0. Let me know if that does not help solving the issue you are facing. 

Regards,

Markus

[stevenminnick]

Markus,

Thanks for the links but I already read though those and they did NOT help.  I think I did it correctly.  Did I not (in my example)?  I read through those links and made the changes and that's what caused my problem. 

Steve

[Simon]

So I can use the controller inner CS logic?  How do I do that?  Was I always using the GPIO line?  

In the spi_nrfx_spim.c driver the inner CS logic is not used. You can see that the .ss_pin is set to NRFX_SPIM_PIN_NOT_USED: https://github.com/nrfconnect/sdk-zephyr/blob/v3.0.99-ncs1/drivers/spi/spi_nrfx_spim.c#L563 and the PSEL.CSN register will not be set. To use that, you need to modify the driver.

The spi_nrfx_spim.c driver instead uses a GPIO pin as CS, and you can see that it gets asserted through spi_context_cs_control(..,true) and deasserted through spi_context_cs_control(.., false) (and spi_context_unlock_unconditionally()).

Instead of modifying the driver to use the inner CS logic, I think it would be better to investigate why it doesn't work using the GPIO line. Could you try to do some debugging and check if the following function _spi_context_cs_control() is reached. If it is, could you check if the port and pin is correct in gpio_pin_set_dt()-->gpio_pin_set()

Best regards,

Simon

[stevenminnick]

Thanks for the help, I don't want to modify drivers.  I just want to use the SPI stuff.  I'm curious why 1.9.1 worked and 2.0.0 doesn't. 

When I debug I get to here:

And if I jump into

spi_context_cs_control(&dev_data->ctx, true);

I get to here:

Which is what I think you were asking me to look into.  But after that it just jumps right out.  I can't debug into there. 

[stevenminnick]

Well I still am not able to debug through spi_context_cs_control(..,true) but I can debug into

spi_context_buffers_setup(&dev_data->ctx, tx_bufs, rx_bufs, 1);

And both pass

&dev_data->ctx

Si in the contect_buffer_setup, that dev_data->ctx is shown here, that looks right doesn't it?  I assume in the next function call for contect_cs_control that's the same.