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

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

Anthony Ambuehl — Fri, 15 Sep 2023 16:23:37 GMT

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.

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

Turbo J — Sat, 09 Sep 2023 21:48:51 GMT

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.

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

hmolesworth — Sat, 09 Sep 2023 20:56:56 GMT

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 :-)

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

Turbo J — Sat, 09 Sep 2023 07:22:15 GMT

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.

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

hmolesworth — Fri, 08 Sep 2023 21:24:00 GMT

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.

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

Turbo J — Fri, 08 Sep 2023 20:55:18 GMT

Read the SPIS chapter in the PS that describes how the SPI slave peripherial works. It is impossible for the CPU to change bytes in a running SPIS transaction, you can only change the next one.

Your protocol design won't work with an MCU as SPI slave. These need noteworthy processing time in order to decide if a packed was valid or not.

This SPI slave protocol would require an asic or FPGA in order to meet the <1µs timing.

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

Anthony Ambuehl — Fri, 08 Sep 2023 18:41:56 GMT

It would be helpful to start, if you could provide a working example for the nrf5340 operating as a SPI Slave within zephyr on NCS 2.3.0. The examples I have found are very old and don't use the pinctrl setup. So far I have not even seen the build attempt to compile the nrfx_spis code.

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

Naeem Maroof — Thu, 07 Sep 2023 15:05:53 GMT

Hello Anthony,

Thank you for contacting DevZone at NordicSemi.
I am not fully sure about your requirements, and whether it could be done or not, but let us start by looking at the documentation.

Some SoC support legacy mode spi and some only use the Spi with EasyDma.
As you are using nrf5340, we see that this SoC (App core) only supports SPI M/S with EasyDma (upto 5 instances).
Next, yes, the UARTE reception generates RXDRDY (receiver ready) event for each byte received. But that is not the case for SPIS. However, SPIS uses RXD.PRT (receive buffer pointer) and generates ENDRX event when RX buffer is filled. We have RXD.MAXCNT register that specifies the maximum number of bytes the SPI slave can receive in one granted transaction.
Maximum SPIS clock frequency can be 8MHz.

I am not sure what suits you, but one thing can be that you configure receiver buffer of size 1, and then after reception of each byte, you will get the ENDRX event as you were looking to have something similar like the UARTE receiver ready event.
Another way can be that, as the received data starts with length field (a number n) and then n-Bytes of data, and another byte; if we consider number n (like 64, or 128) to be 1-byte, then you are actually transmitting n+2 bytes of data. After you receive n+2 byte of data, you can analyze the last byte and then validate the transmission.

In the Zephyr SPI Driver API, the spi_transceive function uses rx_bufs pointer that is of type spi_buf_set. You can set the count variable of this structure to 1 to say that you want 1 byte register buffer.

Best regards,
Naeem