Manual CS control with Zephyr SPI driver

I'm working on adapting ST's RFAL NFC library for ST25R3916B/X-NUCLEO-NFC08A1 on an nRF5340/DK in order to emulate an NFC tag, and would appreciate some insight into how Zephyr's SPI driver works. The RFAL specifies that "[t]he SPI CS must be controlled by SW, not automatically handled by the SPI peripheral." Zephyr does handle it automatically, which is of course usually very useful. ST's example for a STM32 board simply has the chip select/unselect interfaces controlled as GPIO; will it be a problem with Zephyr if I pass GPIO and SPI interfaces to the RFAL and have them both work redundantly?

As an example, the RFAL code looks like this, where the start() and stop() functions only set the CS GPIO low and high as well as stop and start interrupts, respectively. Will Zephyr's SPI driver still work if the CS is already set when it starts? Is there anything else that I should be considering with this SPI interface?

st25r3916comStart();

st25r3916comTxByte( ST25R3916_FIFO_READ, true, false );

st25r3916comRepeatStart();

st25r3916comRx( buf, length );

st25r3916comStop();

Parents
  • Hi,

    Please make sure that your device tree does not define cs-gpios for the SPI peripheral if you want to control it manually. Configure the SPI without the CS line.

    Please also take a look at this thread.

    Regards,

    Priyanka

  • Thanks Priyanka, I'll try that method tomorrow as I'm getting an error with what I ended up doing before your response. I configured the SPI device with have SPI_HOLD_ON_CS so that CS would stay active until released. I #defined st25r3916comStart() to nothing and st25r3916comStop() to spi_release(), and it works for a few dozen cycles before I get the below error. Any ideas? I searched about this error and everyone else seemed to have multiple pins doing the same thing, but I don't have any GPIOs set to SPI pins and that's all I'm using.

Reply
  • Thanks Priyanka, I'll try that method tomorrow as I'm getting an error with what I ended up doing before your response. I configured the SPI device with have SPI_HOLD_ON_CS so that CS would stay active until released. I #defined st25r3916comStart() to nothing and st25r3916comStop() to spi_release(), and it works for a few dozen cycles before I get the below error. Any ideas? I searched about this error and everyone else seemed to have multiple pins doing the same thing, but I don't have any GPIOs set to SPI pins and that's all I'm using.

Children
Related