SPI with SDI only

Help archive
1

Hey,

I have a weird behavior in my application. Maybe somebody has an idea what is going on. I am currently writing a driver for an epaper display. The display only has slave in. There is another mode where the SDI also acts as SDO, but the reference design does not include that.

So, I checked my wire before. I just pulsed the CS PIN. I can see it in my logic analyser. There is also a short pulse of down-up and up-down for SCK and SDI. So, I guess that is the spi_init.

So, the initialization looks like this:


    spi_init_pins(config.SPI_BUS);
    xtimer_usleep(SLEEP_TIME);

    int cs_init = spi_init_cs(config.SPI_BUS, (spi_cs_t) config.CS_PIN);
    if(cs_init != SPI_OK){
        puts("Something went wrong while initializing the SPI bus with the CS PIN");
        return -1;
    }

The Microcontroller crashs after the initialization. ISR stack overflowed by at least 16 bytes. I tried it with spi_init_pins(config.SPI_BUS); alone. That works fine. I am using the hardware MOSI SPI pin. I tried both, the GPIO_PIN and SPI_HWCS.


    gpio_t cs_pin = SPI_HWCS(1);
    gpio_t cs_pin = GPIO_PIN(1, 12);

Has somebody an idea what it potentielly be? I am developing on a bluepill.

2

Hi Philipp,

Hey,

I have a weird behavior in my application. Maybe somebody has an idea what is going on. I am currently writing a driver for an epaper display. The display only has slave in. There is another mode where the SDI also acts as SDO, but the reference design does not include that.

Is the other mode relevant for your driver? I don't think that you can easily handle a changing SDI/SDO line in RIOT. Actually, we don't even provide slave implementations.

So, I checked my wire before. I just pulsed the CS PIN. I can see it in my logic analyser. There is also a short pulse of down-up and up-down for SCK and SDI. So, I guess that is the spi_init.

So, the initialization looks like this:

>spi_init_pins(config.SPI_BUS); xtimer_usleep(SLEEP_TIME); int cs_init = spi_init_cs(config.SPI_BUS, (spi_cs_t) config.CS_PIN); if(cs_init != SPI_OK){ puts("Something went wrong while initializing the SPI bus with the CS PIN"); return -1; } |

AFAIK spi_init_pins() is not a function that needs to called manually. spi_init() initializes all SPI_NUMOF devices during system startup and it utilizes the spi_init_pins() function.

The Microcontroller crashs after the initialization. |ISR stack overflowed by at least 16 bytes. | I tried it with >spi_init_pins(config.SPI_BUS);| alone. That works fine. I am using the hardware MOSI SPI pin. I tried both, the GPIO_PIN and SPI_HWCS.

>gpio_t cs_pin = SPI_HWCS(1); gpio_t cs_pin = GPIO_PIN(1, 12); |

Not 100% sure about the HWCS but if I see it correctly, there is only one HWCS on the bluepill so it would be SPI_HWCS(0), right?

Has somebody an idea what it potentielly be? I am developing on a bluepill.

Does test/periph_spi work as expected on your side? I don't have concrete suggestions right now. Can you point to a branch including test application to reproduce the issue?

Cheers Peter

3

My mistake. Everything is fine :slight_smile: The SDI/SDO on one pin is not necessary, even if it would be nice to get some feedback. I still need to figure out though why the display is not refreshing, even when the data input looks fine in the logicAnalayser. The busy pin has also an expected behavior.