SPIS spi_transceive returns but no data in rx/tx buffers

[Anthony Ambuehl]

NCS v2.3.0

nrf5340dk_nrf5340_cpuapp_ns

Devicetree is configured so SPI2 is a SPIS.  

My calls to spi_transceive are waiting for the SPI operation but when the spi operation is complete spi_transceive returns but rx and tx data sent is 0.

I have a SPIS POC which is working but it is not in a TFM environment.   In the POC (non-TFM) environment I confirm the SPIS2 secure peripheral settings are identical to the settings configured into the non-secure peripheral.  The only difference is the "amount" register for secure peripheral reports 0 data received.

Any suggestions why no data would be received?  

[Anthony Ambuehl]

As another data point, I put my complete module for the SPIS driver into a non-TFM environment and it is working fine there, so this seems to be somehow related to the TFM non-secure environment.  Both environments used identical device tree configuration and hardware.  

[Susheel Nuguru]

Did you sniff on the SPI pins with Logicanalyzer or oscilloscope? Do you see if there is any data being transferred on the pins? If not, then there might be a misconfiguration of the pins either on the nRF or master side. What is connected on the master side?

[Anthony Ambuehl]

The PINS are not misconfigured, but no data is transmitted.

1) I used the identical device tree configuration on a non-TFM envrionment and data was transmitted.

2) I captured the SPIS configuration (shown in my original post in the side-by-side images above)  and the pins are configured the same in both enviornments.

3) Although the MAXCNT are the same in both environments, the TFM build shows 0 in the "AMOUNT" register while the non-TFM environment shows the correct number of bytes.

I'm wondering if the non-secure peripheral has a hardware bug?  Or perhaps there is some issue with the SPIS driver.

[hmolesworth]

Does SEMSTAT  differ? Might be the issue ..

7.31.6.14 SEMSTAT Address offset: 0x400
Semaphore status register
 0 Semaphore is free
 1 Semaphore is assigned to CPU
 2 Semaphore is assigned to SPI slave
 3 Semaphore is assigned to SPI but a handover to the CPU is pending

[Anthony Ambuehl]

I found the root cause.  On nrf5340dk the pins P1.0 and P1.1 are used by the cpunet for the UART.