async SPI example

Dear all,

I tried this example regarding async SPI:

 https://github.com/too1/ncs-spi-master-slave-example

I also wrote overlay for this example to work on nrf52840 dongle:

&pinctrl {
    spi_master_default: spi_master_default {
        group1 {
            psels = <NRF_PSEL(SPIM_SCK, 0, 31)>,
                    <NRF_PSEL(SPIM_MOSI, 0, 29)>,
                    <NRF_PSEL(SPIM_MISO, 0, 13)>;
        };
    };

    spi_master_sleep: spi_master_sleep {
        group1 {
            psels = <NRF_PSEL(SPIM_SCK, 0, 31)>,
                    <NRF_PSEL(SPIM_MOSI, 0, 29)>,
                    <NRF_PSEL(SPIM_MISO, 0, 13)>;
            low-power-enable;
        };
    };

    spi_slave_default: spi_slave_default {
        group1 {
            psels = <NRF_PSEL(SPIS_SCK, 0, 9)>,
                    <NRF_PSEL(SPIS_MOSI, 0, 10)>,
                    <NRF_PSEL(SPIS_MISO, 1, 10)>,
                    <NRF_PSEL(SPIS_CSN, 1, 15)>;
        };
    };

    spi_slave_sleep: spi_slave_sleep {
        group1 {
            psels = <NRF_PSEL(SPIS_SCK, 0, 9)>,
                    <NRF_PSEL(SPIS_MOSI, 0, 10)>,
                    <NRF_PSEL(SPIS_MISO, 1, 10)>,
                    <NRF_PSEL(SPIS_CSN, 1, 15)>;
            low-power-enable;
        };
    };
};

my_spi_master: &spi1 {
    compatible = "nordic,nrf-spim";
    status = "okay";
    pinctrl-0 = <&spi_master_default>;
    pinctrl-1 = <&spi_master_sleep>;
    pinctrl-names = "default", "sleep";
    cs-gpios = <&gpio0 15 GPIO_ACTIVE_LOW>;
    reg_my_spi_master: spi-dev-a@0 {
        reg = <0>;
    };
};

my_spi_slave: &spi0 {
    compatible = "nordic,nrf-spis";
    status = "okay";
    pinctrl-0 = <&spi_slave_default>;
    pinctrl-1 = <&spi_slave_sleep>;
    pinctrl-names = "default", "sleep";
    def-char = <0x00>;
};

// By default uart1 will occupy P1.01 and P1.02. In order to make these pins available, disable uart1
&uart1 {
    status="disabled";
};
&i2c1{
    status="disabled";
};

I physically connected these GPIO pins together:

0, 31 with 0, 9

0, 29 with 0.10

0, 13 with 1.10

1.15 with 0.15

But when I use PulseView with dataanalyzer, I only see mangled data being send on MOSI and MISO, I think the problem could be with CS handling since the data bits are misaligned with CS being  0:

D3=CLK

D7=MISO

D1=MOSI

D5=CS

I guess there is not condition that Master has to be spi0 and slave has to be spi1, right?

Could anyone help me resolve this issue?

Thank you

Ivo

  • Hi

    Susheel is currently out of office, so I'm taking care of this ticket while he's away. You say you have connected some of the GPIOs together, so have you made sure that these pins don't have conflicting roles at all. P0.09 and P0.10 being one such conflict, but it could also be that any of these other pins are defined as something else in your project too, so please double check that.

    Best regards,

    Simon

  • Actually, here is the github repository of the async-spi-master-slave-communication example with one person raising an issue with very simmilar problem I face:

    https://github.com/too1/ncs-spi-master-slave-example/issues/2

    That person seems doing everything right just according to the description of the example with no success running the code.

    One of Nordic engineers recommends this example as a reference at the end of this conversation

    devzone.nordicsemi.com/.../spi-chip-select-in-device-tree-overlay-in-zephyr

     

    So I would really consider it as a reference:

    Let's dive to the chip select functionality.In the code there is reference to chip select PIN for master configured this way:

    DTS:

    cs-gpios = <&gpio0 15 GPIO_ACTIVE_LOW>;
    reg_my_spi0: spi-dev-a@0 {
    reg = <0>;
    };

    C code:

    .cs = {.gpio = MY_SPI_MASTER_CS_DT_SPEC, .delay = 0},

    What is rather confusing for me is how the chip select for a slave ibeing set in the main.c.

    I am fully aware of the fact that chip select of a slave is somehow mentioned in DTS file via <NRF_PSEL(SPIS_CSN, 1, 15)>;

    But how is the chip select specified for slave in C code?

    I only see spi configuration for slave in C code this way:

    static const struct spi_config spi_slave_cfg = {
    .operation = SPI_WORD_SET(8) | SPI_TRANSFER_MSB |
    SPI_MODE_CPOL | SPI_MODE_CPHA | SPI_OP_MODE_SLAVE,
    .frequency = 4000000,
    .slave = 0,
    };

    But how does the program recognizes that the slave should receive chip select signal on pin 1.15 being sent from gpio master chip 0.15?

    Is it linked to the slave automatically somehow via DTS or do I have to specify it for slave  explicitly via code in struct spi_config the same way it is specified for master?

    In the example code, there is no need to specify the CS for slave, but the example does not work for me nor for the other guy. I really do not know, what I am doing wrong.

  • Hi

    Just to make sure, you said in your first reply to Susheel that you're not using the nRF Connect SDK, but Zephyr version 3.6.99. Can you confirm that you're not using the nRF Connect SDK at all or please let us know what version you're using. The sample you link to was made for and tested on nRF Connect SDK v2.5.2, and has not been tested on vanilla Zephyr. Maybe the Zephyr discord channel is a better place to ask about these issues.

    Best regards,

    Simon

  • I am using vanilla Zephyr,the other person who is included in unresolved issues on github repository raised an issue in 2023 experiencing the same symptoms and he was using NRF SDK.

    Anyway,despite one more bug in the example,the solution was to update to up to date Zephyr version. Zephyr 3.6.99 is probably too old,maybe from 2023?

    I am using nrf hardware because I find it excellent,but I prefer vanilla Zephyr,I still think many people benefit from resolving pure Zephyr issues as many things are shared across Zephyr and NRF SDK and to top it all still buying nrf boards or bare nrf chips.

  • I see, and we'll try to help you as best we can. But at this point I think we should wait for Susheel to return. He should be back on Friday and be able to take a better look at this as he's better versed in Zephyr than me.

    Best regards,

    Simon

Related