Is it possible by any chance to have the SPIS working on an nRF52 without using the CS pin?
Is it possible by any chance to have the SPIS working on an nRF52 without using the CS pin?
Hi,
As described in the product specification of nRF52832, the SPI Slave interface use two memory pointers, RXD.PTR and TXD.PTR, to point to memory buffers. As these are located in RAM, they can be accessed by both CPU and the SPIS interface. A semaphore is used to aquire access to these registers, to avoid interfering with CPU activity. The semaphore is tried aquired on CSN pin low drive, and released when CSN goes high again. It is therefore not possible to use SPIS without the CSN pin, as this signal is needed to know when to aquire the semaphore.
Best regards,
Jørgen
Hi,
As described in the product specification of nRF52832, the SPI Slave interface use two memory pointers, RXD.PTR and TXD.PTR, to point to memory buffers. As these are located in RAM, they can be accessed by both CPU and the SPIS interface. A semaphore is used to aquire access to these registers, to avoid interfering with CPU activity. The semaphore is tried aquired on CSN pin low drive, and released when CSN goes high again. It is therefore not possible to use SPIS without the CSN pin, as this signal is needed to know when to aquire the semaphore.
Best regards,
Jørgen
What about if I use a pin which is not connected to the master but it's hold permanently low on the slave? This way the SPIS thinks it can always grant the semaphore. Could this work?
No, the CS is connected to the semaphore aquire request, and this have to be relased between each SPI transfer. By tying CS permanently low, the semaphore will never get released and this will prevent CPU from accessing the buffers.
From my understanding the semaphore for the CPU is only a method to know whether the SPIS is writing into those buffers, but it doesn't prevent the CPU access.
"The semaphore mechanism does not, at any time, prevent the CPU from performing read or write access to the RXD.PTR register, the TXD.PTR registers, or the RAM that these pointers are pointing to. The semaphore is only telling when these can be updated by the CPU so that safe sharing is achieved."
Yes, but it is still implemented in such a way that the CPU will aquire the semaphore when accessing the registers. If CSN is set low, the CPU will not aquire the semaphore until a rising edge of CSN is detected. The semaphore must also be reaquired by the SPI slave interface again for each transfer. I guess it could be possible to ignore this semaphore safety mechanism by accessing the registers directly, but then you will have no control over the validity of the data in the registers. This is not something that is supported by our drivers.