When the SPIS (SPI Slave) of Nordic 5340 receives data from the SPIM (SPI Master) of STM32, one data packet is delayed by 20 milliseconds every second, which causes voice stuttering.

[LouisQiu27th]

The STM32 chip collects audio data with the following audio parameters: a sampling frequency of 44 kHz, a sampling precision of 16 bits, and a single channel. The STM32 chip transmits the data to the Nordic 5340 via SPIM (SPI Master mode), while the Nordic 5340 receives the data in SPIS (SPI Slave mode) and then sends it out through the network.

Through testing, it has been confirmed that there are no issues with the audio sampling process, the transmission side of the STM32, or the network transmission side of the Nordic 5340. However, when the Nordic 5340 operates as an SPI Slave, it periodically experiences choppiness and delays: approximately once per second, there is a reception delay of more than 20 ms. This delay leads to packet loss and ultimately results in choppy audio playback.

[LouisQiu27th]

The STM32 uses SPIM (SPI Master mode) with a communication frequency of 25 MHz. According to what the FAE (Field Application Engineer) told me, the maximum frequency supported by Nordic's SPIS (SPI Slave mode) is 8 MHz.

For the Nordic 5340, I am using the NCS (nRF Connect SDK) version 2.5.0. Initially, I used the spi_transceive_signal function to receive data packets, but encountered issues. The FAE then advised me to try the nrfx SPI driver instead. Following this suggestion, I implemented the data reception using a combination of functions from the nrfx_spis.h header file. However, the reception delay issue still persists.

[Kenneth]

Hello,

Are you sure this is not due to differences in clock between peers in the system, and what you experience is due to buffer underrun or overrun?

Kenneth

[LouisQiu27th]

First of all, none of these are the root cause. The STM32 chip has been widely and maturely used in our other systems, with a large shipment volume from the company. There are no issues with data acquisition or SPIM transmission on the STM32 side.

The clock for the nRF5340's SPIS is derived from the SPIM. Furthermore, I have also conducted a test where the STM32 sends a single 20-byte data packet every 60 milliseconds. In this scenario, the nRF5340's SPIS still exhibits a phenomenon where one data packet is received slowly per second—it takes 90 milliseconds to receive that specific packet, while the average reception time is 60 milliseconds.

Currently, my suspicion is whether the system has enabled the default configuration of the nRF5340 entering sleep mode every second, which thereby affects the functionality of the SPIS. 

[Kenneth]

Not sure I quite understand, normally as an SPI master you just pass the 20byte, how do you observe that the nRF5340 sometimes use 90ms instead of 60ms to receive the data? Are you using some handshaking of some sort, is the delay before or after the SPI master try to write the data?

Kenneth

[LouisQiu27th]

I use the log version, which prints timestamps. The SPI master sends a packet at 60ms intervals, and I calculate the interval difference between consecutive packets received by the SPI slave. Additionally, the first two bytes of each packet contain a counter, allowing me to check for any packet loss.