About nrf51822 as SPI-Slave

RE: About nrf51822 as SPI-Slave

Jørgen Holmefjord — Thu, 30 Aug 2018 09:14:50 GMT

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.

RE: About nrf51822 as SPI-Slave

John_Doe — Thu, 30 Aug 2018 08:59:39 GMT

Hi,

About the first question, Do you mean that SPIS module needs falling edge of CS pin to acquire the semaphore? And in my case, after nrf51822 initialing spis module and signal master to send data (CS pin is low during that time), master need to, Pull high CS pin -> Pull low CS pin -> SPI data transmition?

Thanks.

RE: About nrf51822 as SPI-Slave

Jørgen Holmefjord — Thu, 30 Aug 2018 08:48:28 GMT

Hi,

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.
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