Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Can't read or write SPIS data on NRF52 GPIO

Hello,

I have developed an SPIS interface on a custom board using the nRF51. I also implemented an SPI interface on a nRF51-DK board and have had the two boards talking to one another for a couple of months now.

Now I am trying to port my SPIS implementation onto a custom board using the nRF52 and have some problems. I am using pins P0.22, P0.23, P0.24, and P0.25 for the SPIS port. When the master (nRF51-DK) completes a transfer, I do receive the NRF_DRV_SPIS_XFER_DONE event. However, my Rx buffer is empty and I see no data being transmitted on MISO. It is as if my buffers have not been set but I have confirmed that they are.

In an unrelated issue, I noticed that I was unable to control P0.09 and P0.10. After some digging I discovered I needed to set the CONFIG_NFCT_PINS_AS_GPIOS preprocessor symbol before those pins would behave as GPIO's. Given the proximity of the antenna to my SPIS pins, I am wondering if there is something similar that I need to do to configure these pins to work properly.

Thanks

  • To clarify my question, I notice in the product specification that GPIO 22 through 31 are considered "near" the radio and recommended for low drive and low frequency. A 4Mbit or 8Mbit SPI clock would be high frequency but I am not using the radio in this design so I shouldn't have a problem. Is there something in the chip that would block or filter a high frequency signal like an SPI clock that would make it unable to clock data in or out? 

  • David Andresky said:
    Is there something in the chip that would block or filter a high frequency signal like an SPI clock that would make it unable to clock data in or out?

    No.

    Is there reason why you can't use the SPIS driver in nRF5 SDKv15.2 directly? I understand the api is different, but the example is found here:
    \nRF5_SDK_15.2.0_9412b96\examples\peripheral\spis 

    Best regards,
    Kenneth

  • Sorry, I am on SDK 12.3. That said, I do use the SPIS driver directly. My code module simply manages the buffers and uses a timer or buffer full event to interrupt the master device so that a transfer can be scheduled.

    As I said, my code and use of the driver works on the nrf51. I am using the same code on both chips, I simply set different I/O pins for the SPI port.

    Is there a way to watch the SPI clock in code to verify that data is actually being clocked in and out? I have suspected that this is not happening but it seems I can only break on transfer complete events which only signals that chip select was deasserted, but doesn't tell me if anything was actually clocked in.

  • Don't you have a logic analyzer to observe the CSN, CLK, MISO, and MOSI pins?

    Mu suggestion is to look into other peripherals that may be controlling the pins and/or try different pins for test.

  • Yes, of course. If it wasn't clear, I have no issue with my master device. Yes I have observed a clock signal and data on MOSI with my analyzer. 

    The problem is on the slave side. When I look at the Rx buffer after the XFER_DONE event, it is empty, despite having data on MOSI. I also see no data on MISO despite having a Tx buffer with data to be transferred. 

    The XFER_DONE event only tells me when CS goes high. This issue looks as though the slave is not seeing the clock.

    I was hoping there was some preprocessor symbol in the SDK like for pins P0.09 and P0.10 that would enable the GPIO. Lacking that, I am looking for a way to put a break or watch point in the slave code so I can see that byte to byte transfers are actually happening.

    I have looked at other peripherals. I use SPIS1, UART0, and SPI0 which do not share base addresses.

    I have routed the clock to another pin that was not "near" the radio and saw the same behavior.

Related