About nrf51822 as SPI-Slave

[John_Doe]

Hi Nordic,

I am using SDK 12.3.0, S130 2.0.1 and PCA10028 nrf51 DK.

I would like to use nrf51822 as SPI slave and other MCU as SPI master. I am using spis_pca10028 example as a starting point.

And here are some questions about SPIS,

1. Can I use CS pin as external interrupt for nrf51822 first? When master pull low cs pin, nrf51822 would wake up and init spis module by calling nrf_drv_spis_init(). And then nrf51822 would pull low a READY pin to signal master to send data through SPI. And finally, cs pin would be pulled high by master and nrf51822 would uninit spis module, set cs pin as external interrupt again and pull high READY pin. Please be aware that cs pin would be low during spis init and spi communication. I am worried about the semaphore acquire and release because the cs pin is always low during spis init and spi communication.

2. In spis example, the program setup the TX buffer before spi communication by calling nrf_drv_spis_buffers_set() and then wait for event. Can I call nrf_drv_spis_buffers_set again during SPI communication? I want to process the received data and then determine what is the reply message. Or slave can only send dummy bytes in first communication and then send reply message in next spi communication.

Thanks.

[Jørgen Holmefjord]

Hi,

1. No, this will not work. You will need to pull the CSN pin low after SPIS is initialized in order to aquire the semaphore. I would recommend that you first set the pin low using a GPIO, and then pull it low again after the SPIS driver have been initialized. You can have a look at the pin_change_interrupt example to get an idea of how to add code to init SPIS on pin changes. Make sure you disable the pin interrupt before initializing SPIS on the same pin.
2. You cannot safely update the data pointers during a transfer, as the CPU needs to aquire the semaphore first. The semaphore is aquired by the SPIS peripheral while a transfer is ongoing. From documentation: 

Before the CPU can safely update the RXDPTR and TXDPTR pointers it must first acquire the SPI semaphore. The CPU can acquire the semaphore by triggering the ACQUIRE task and then receiving the ACQUIRED event. When the CPU has updated the RXDPTR and TXDPTR pointers the CPU must release the semaphore before the SPI slave will be able to acquire it.

Best regards,
Jørgen

[Jørgen Holmefjord]

Yes, this is the statement from the reference manual: "The SPI slave will try to acquire the semaphore when CSN goes low". I have not tested with leaving the CSN low during SPIS init, but I doubt that this will work. Feel free to try it and report back your findings though.