nRF5340: Debugging SPI + Implementing SPI + PPI

Hello,

I have a question regarding 1. debugging SPI and 2. implementing SPI + PPI + FORK. It would be really appreciated if anyone could help me with this. 

Debugging SPI

In order to connect SPI and PPI, I need to use nrfx library. I have a working example that is using zephyr library. There is a sample from devZone that is using nrfx library. I made an adjustment (SCK, MISO, MOSI, CS pins) but seems like it's not working.

-- In zephyr +overlay version, I could set those pins to "gpio1" and pin 4,5,6,7 in overlay. But in nrfx version, I could only set pin numbers to 4,5,6,7. Is there any way I could set it to gpio1 specifically?

-- Since I would like to do "read" operation, I am checking "m_rx_buf" in nrfx version. But the buffer is always filled with 0. With zephyr version, I can read the number I expect.

Please let me know if there is anything I am missing. 

Implementing SPI + PPI + FORK

I found in order to connect SPI and PPI, I need to set NRFX_SPIM_FLAG_HOLD_XFER flag for SPI and configure CS to  NRFX_SPIM_PIN_NOT_USED and manage it outside the driver. This suggests using fork. Is there any example code I can follow for this? 

Thank you,

Parents
  • Hi,

    There is a sample from devZone that is using nrfx library.

    Can you post a link to the sample for reference?

    -- In zephyr +overlay version, I could set those pins to "gpio1" and pin 4,5,6,7 in overlay. But in nrfx version, I could only set pin numbers to 4,5,6,7. Is there any way I could set it to gpio1 specifically?

    The port is set as the 5th bit in the PSEL registers of the peripheral, which corresponds to adding 32 to the pin number to assign a pin on port1. You can use the macro NRF_GPIO_PIN_MAP(portpin) when defining the pins in your application.

    -- Since I would like to do "read" operation, I am checking "m_rx_buf" in nrfx version. But the buffer is always filled with 0. With zephyr version, I can read the number I expect.

    It is possible that some of the pins you have assigned to SPIM peripheral is also assigned to another peripheral in the application, preventing the slave to output the correct data. Have you checked the SPIM pins with a logic analyzer/scope, to see if there is activity on the lines as expected?

    I found in order to connect SPI and PPI, I need to set NRFX_SPIM_FLAG_HOLD_XFER flag for SPI and configure CS to  NRFX_SPIM_PIN_NOT_USED and manage it outside the driver. This suggests using fork. Is there any example code I can follow for this? 

    We do not have any example code showing how to do automatic control of SPI CS pin through PPI and TIMER. Have you tried to implement this yourself? Do you have any specific issues?

    Best regards,
    Jørgen

Reply
  • Hi,

    There is a sample from devZone that is using nrfx library.

    Can you post a link to the sample for reference?

    -- In zephyr +overlay version, I could set those pins to "gpio1" and pin 4,5,6,7 in overlay. But in nrfx version, I could only set pin numbers to 4,5,6,7. Is there any way I could set it to gpio1 specifically?

    The port is set as the 5th bit in the PSEL registers of the peripheral, which corresponds to adding 32 to the pin number to assign a pin on port1. You can use the macro NRF_GPIO_PIN_MAP(portpin) when defining the pins in your application.

    -- Since I would like to do "read" operation, I am checking "m_rx_buf" in nrfx version. But the buffer is always filled with 0. With zephyr version, I can read the number I expect.

    It is possible that some of the pins you have assigned to SPIM peripheral is also assigned to another peripheral in the application, preventing the slave to output the correct data. Have you checked the SPIM pins with a logic analyzer/scope, to see if there is activity on the lines as expected?

    I found in order to connect SPI and PPI, I need to set NRFX_SPIM_FLAG_HOLD_XFER flag for SPI and configure CS to  NRFX_SPIM_PIN_NOT_USED and manage it outside the driver. This suggests using fork. Is there any example code I can follow for this? 

    We do not have any example code showing how to do automatic control of SPI CS pin through PPI and TIMER. Have you tried to implement this yourself? Do you have any specific issues?

    Best regards,
    Jørgen

Children
  • Can you post a link to the sample for reference?

    --I cannot recall where I found, but here is the original zip file: 6136.nrfx_spi_master.zip

    It is possible that some of the pins you have assigned to SPIM peripheral is also assigned to another peripheral in the application, preventing the slave to output the correct data. Have you checked the SPIM pins with a logic analyzer/scope, to see if there is activity on the lines as expected?

    -- Yes. I tested and SCK, MOSI, MISO, CS pins are called correctly. But I still don't see m_rx_buf getting filled with correct data. Do you have any idea in this case?

    Here is another question,

    Q: Is it not possible to use nrfx's SPIM and zephyr's I2C in the same project? It seems like once I call "nrfx_spim_init()", call for "i2c_burst_read()" always returns an error. 

    Thank you,

    Skim.

  • skim said:
    --I cannot recall where I found, but here is the original zip file: 6136.nrfx_spi_master.zip

    I think this might come from this post.

    skim said:
    -- Yes. I tested and SCK, MOSI, MISO, CS pins are called correctly. But I still don't see m_rx_buf getting filled with correct data. Do you have any idea in this case?

    If MISO toggles as expected externally, I suspect that the GPIO assigned to MISO in the nRF chip is also used for something else. Can you upload the compiled dts file for your build? (Found in build\zephyr\zephyr.dts).

    skim said:
    Q: Is it not possible to use nrfx's SPIM and zephyr's I2C in the same project? It seems like once I call "nrfx_spim_init()", call for "i2c_burst_read()" always returns an error. 

    I do think this should be possible, but note that most of the SPIM and TWIM instances share base address, meaning you can only enable one protocol for each instance (e.g. either TWIM0 or SPIM0) at a time (can be reconfigured at runtime if using nrfx drivers). 

Related