Can't read or write SPIS data on NRF52 GPIO

[David Andresky]

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

[Kenneth]

Then my only suggest is to take the spis example from the SDK as-is, verify that it works, and then compare SPIS configuration between the two. There is likely something missing here, though I don't understand exactly what. It looks like the CLK signal is not received yes, so a start would be to look there. I assume you have shared GND between the boards.

Best regards,
Kenneth

[David Andresky]

I see the problem now. I did some experimentation with the DEF and ORC characters and found that the slave was in fact clocking out data. The issue was that it was clocking out the ORC character which had a default value of 255 so it looked like it wasn't clocking out anything at all. As soon as I changed it to a different number I could see that every byte of the transfer from the NRF52 was the ORC character.

According to the product specification, if the transfer exceeds the values in the MAXTX and MAXRX registers, then received data will be dropped and excess transmitted data will be the ORC character. This is what I was seeing.

The reason I see this:

When I developed the SPI interface for the NRF51, the SDK had a limit on the size of transfers at 255 bytes. We wanted to do larger transfers so I revised the SDK files to allow 16-bit numbers for the transfer size instead of 8-bit.

The transfer size we settled on was 1024 bytes and everything has worked great for two or three months now.

The NRF52 however seems to force a 255 byte limit. When I set a transfer size of 1024 bytes, that effectively sets the lower 8 bits of the MAXTX and MAXRX registers at 0, which means all received data will be dropped and all transmitted data will be the ORC character.

If I set the transfer size to 1027 bytes, then MAXTX and MAXRX will be 3 and I will receive and transmit just 3 bytes. If I set it to 1023 they will be 255 and so on.

I am hoping there is just something in the SDK specific to the NRF52 that I missed and I can continue to specify transfers larger than 255 bytes. Can you let me know if that is the case, or why the NRF51 allows it but the NRF52 doesn't?

[hmolesworth]

The SPI hardware limit on nRF52832 is 256 bytes; that doesn't apply to the nRF52840, which should work for you.