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

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

Jason — Sat, 26 Nov 2022 09:58:20 GMT

Thank you for this!

I've had this on my todo list because they removed gpio_dev in 2.1.0 and I didn't notice that all I had to do was this one line change.

"port" is a bad name for a device

THANK YOU!

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

Simon — Thu, 28 Jul 2022 10:02:28 GMT

Thanks for sharing your solution!

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

stevenminnick — Wed, 27 Jul 2022 18:26:34 GMT

So I think I found the answer on my own.

This seems to work, I have commended out the old stuff and left in the new stuff

static struct spi_cs_control spi_cs = {
    // this is the new hottness
    .gpio.pin = 18,
    .gpio.dt_flags = GPIO_ACTIVE_LOW,

    // below is the old depricated way
    // .gpio_dev = NULL,
    // .gpio_pin = 18,
    // .gpio_dt_flags = GPIO_ACTIVE_LOW,
    // .delay = 0,
  };

    // old and busted
    //spi_cs.gpio_dev = gpioPort0;
    // new hottness
    spi_cs.gpio.port = gpioPort0;

This is from SPI.H

struct spi_cs_control {
    /**
     * GPIO devicetree specification of CS GPIO.
     * The device pointer can be set to NULL to fully inhibit CS control if
     * necessary. The GPIO flags GPIO_ACTIVE_LOW/GPIO_ACTIVE_HIGH should be
     * equivalent to SPI_CS_ACTIVE_HIGH/SPI_CS_ACTIVE_LOW options in struct
     * spi_config.
     */
    union {
        struct gpio_dt_spec gpio;
        struct {
            const struct device *gpio_dev __deprecated;
            gpio_pin_t gpio_pin __deprecated;
            gpio_dt_flags_t gpio_dt_flags __deprecated;
        };
    };
    /**
     * Delay in microseconds to wait before starting the
     * transmission and before releasing the CS line.
     */
    uint32_t delay;
};

And this is from GPIO.H

/**
 * @brief Container for GPIO pin information specified in devicetree
 *
 * This type contains a pointer to a GPIO device, pin number for a pin
 * controlled by that device, and the subset of pin configuration
 * flags which may be given in devicetree.
 *
 * @see GPIO_DT_SPEC_GET_BY_IDX
 * @see GPIO_DT_SPEC_GET_BY_IDX_OR
 * @see GPIO_DT_SPEC_GET
 * @see GPIO_DT_SPEC_GET_OR
 */
struct gpio_dt_spec {
    /** GPIO device controlling the pin */
    const struct device *port;
    /** The pin's number on the device */
    gpio_pin_t pin;
    /** The pin's configuration flags as specified in devicetree */
    gpio_dt_flags_t dt_flags;
};

I think they want us to use the gpio_dt_spec struct from now on, not the old structure in that union.

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

Simon — Wed, 06 Jul 2022 09:34:44 GMT

I tried to investigate this.

I figured out that the CS pin set by DTS would eventually end up in dev->data->ctx->cs_gpios->pin and the CS pin set through the API would eventually end up in dev->data->ctx->config->cs->gpio->pin (this is used when asserting/deasserting CS).

So it seems like setting CS through DTS does nothing, if my findings are correct. I will continue to investigate and also look at v1.9.1 and how it was done there

Best regards,

Simon

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

stevenminnick — Thu, 30 Jun 2022 16:33:32 GMT

Here is some other weirdness. My FAE has also been thinking about this and he emailed me:

But you have

.gpio dev set to NULL

I think it needs to.point to a structure set in the binding of the gpio port

Creating a structure with the binding of the node label "GPIO_0"

so I think he was referring to

static struct spi_cs_control spi_cs = {
    .gpio_dev = NULL,
    .gpio_pin = 25,
    .gpio_dt_flags = GPIO_ACTIVE_LOW,
    .delay = 0,
  };

now all the examples I have seen with SPI had .gpio_dev set to NULL. And it worked in SDK 1.9.1. But since I'm in a "I'll try anything" I did this:

const struct device *gpioPort0;

gpioPort0 = device_get_binding("GPIO_0");

spi_cs.gpio_dev = gpioPort0;

By setting .gpio_dev to that, I get the compiler message that .gpio_dev is deprecated:

But that made the CS line work.

Before setting .gpio_dev

After setting that

So is .gpio_dev deprecated? Does that mean I should stop using it? Why was this not needed in 1.9.1 and it's now needed in 2.0.0? And if it's deprecated is there something else I should be doing to make the CS line work with SPI in SDK 2.0.0?

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

stevenminnick — Thu, 30 Jun 2022 13:49:54 GMT

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.

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

stevenminnick — Thu, 30 Jun 2022 13:29:40 GMT

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.

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

Simon — Thu, 30 Jun 2022 13:08:30 GMT

[quote user=""]So I can use the controller inner CS logic? How do I do that? Was I always using the GPIO line? [/quote]

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

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

stevenminnick — Wed, 29 Jun 2022 13:32:52 GMT

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

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

Albrecht Markus Schellenberger — Wed, 29 Jun 2022 06:34:58 GMT

Hello Steven,

[quote user=""]So I can use the controller inner CS logic? How do I do that? Was I always using the GPIO line? [/quote]

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