NRF5340 SPIS is it possible to update tx data during a transceive operation based on received data?

[Anthony Ambuehl]

I'm working with Zephyr using NCS 2.3.0.  The boards include nrf5340 and nrf9160.  

Project lead has specified that the nrt5340 shall operate as a SPI slave to the nrf9160.  The communication protocol calls for validating the received data on the fly as its received.  The received data starts with a length field.  The design specifies that after the indicated length of data is transceived, the spi master will clock out an additional byte and the slave should send a value  indicating whether the data received was found to be valid... essentially an ACK/NACK based on the received data.  The goal is to operate the SPI bus at up to 1 MHz.

For the UARTE interface I see there is an RXDY event after each byte is received, which allows simple byte-by-byte operation. I don't see anything similar in the SPIS peripheral.

Is this design feasible using the SPIS peripheral without an RXRDY event? 

Is it possible to return control to the caller of spi_tranceive after each byte without losing any data in the overall SPI transmission?  Given the 1 microsecond clock time, it seems like a very tight timing constraint to initiate another spi_transceive before the next byte starts clocking out.

[hmolesworth]

Yes, but not quite as you may be thinking. Use a single SPI transaction thus:

<CS low><Tx: Length byte><Tx: Length Data Bytes><Twiddle Thumbs with no clocks or data><Tx: Dummy Byte to read Ack/Nack><CS High>

The Master actually uses two transactions, length bytes and a single byte, separated by a long enough interval to allow the Slave to calculate the Ack/Nak and all within a single CS such that the slave only sees a single SPI transaction with a pause in clocking, perfectly acceptable. The Slave can change any byte in the queue for response up until the receive clock edge changes.

[Turbo J]

The NRF SPIS peripherial does not allow changing bytes during a transaction (CS=low). Read the PS for details, but this is a basic requirement that allows the SPIS to run at a relatively high speed.

I strongly recommend a protocol redesign with this hardware limitation in mind.

[hmolesworth]

Yes the hardware semaphore in the nRF5340 SPIS is a nice feature, but no it does not preclude the scheme I suggested for changing the last byte in the Tx buffer prior to transmission. From Product Spec v1.3 (latest to hand):

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

I agree there is risk here if the timing of <Twiddle Thumbs with no clocks or data> is too short, but that's up to the user. A protocol redesign may be the recommended path, but I like my idea :-)

[Turbo J]

I strongly suspect that there is a hardware fifo in place that would read the following byte too soon - it should latch it during the transmission of the previous byte. Keep in mind that you need the first bit ready very soon at full speed, thus the RAM access has to be well in advance.

You are free to try your luck.

[Anthony Ambuehl]

Once the pointers/buffers have been set and the CSN goes low I believe it is not possible to change the pointers due to the locking semaphore in the hardware.   While it might be possible to update the RAM the txptr will reach later in the transmission, this seems like a very tricky and failure prone approach.  I will ask for the design to be changed.