Problem with STM32U5G9 SPI DMA transfers

[G_Anastasopoulos]

Dear All,

I am interfacing my STM32U5G9 device with VS1011 audio decoder, over SPI using DMA.

My setup mostly works, I can configure the decoder send and receive data from the chip.

But over a long period of time (hours of having the device running) I am no longer able to send data and I see that my SPI peripheral is effectively in a stuck state. The registers of the SPI and the DMA in that state are shown below and they are not changing over a reasonable amount of time:
SPI1 peripheral configuration:

and the SPI registers when the peripheral is stuck:

DMA configuration:

and the DMA registers when the device is stuck:

From what I gather from the manual, at this stage the peripheral has 2 packets that it's supposed to send (DMA CBR1 register) and there is nothing happening based on the CSR register, is this correct?
Is there a specific issue revealed by the values of the registers?
Is there something that can be done configuration wise to avoid this issue?
Is there anything that can be done at run time that if this situation is encountered to "reset" the peripheral and continue normal operation?

Thank you very much in advance.

[Saket_Om]

Hello @G_Anastasopoulos 

On which instruction the SPI is getting stack ? 

---

@G_Anastasopoulos wrote:

Is there anything that can be done at run time that if this situation is encountered to "reset" the peripheral and continue normal operation?

---

You can abort the ongoing transfer using HAL_SPI_Abort(), Deinit and Init the SPI peripheral and restart a new one. 

[G_Anastasopoulos]

Dear @Saket_Om 
Thank you very much for your reply.

To begin with I am not sure how to detect the problem, as the HAL_SPI_ErrorCallback is not called at all, so I am not sure when and where I should perform the sequence you mentioned.

Second, there could be 2 points that might be causing the observed:

When calling the HAL_SPI_Transmit_DMA or when calling this function:

static HAL_StatusTypeDef SPI_DMA_Resume(SPI_HandleTypeDef* hspi) {

 if (hspi->Instance == SPI1) {
 /* Process Locked */
 __HAL_LOCK(hspi);

 /* Enable the SPI DMA Tx & Rx requests */
 SET_BIT(hspi->Instance->CFG1, SPI_CFG1_TXDMAEN | SPI_CFG1_RXDMAEN);

 /* Process Unlocked */
 __HAL_UNLOCK(hspi);
 }
 return HAL_OK;
}

So far I have not been able to identify the exact moment that the peripheral gets stuck, but what I have found out is that when the device is stuck the way I described before, the SR register has the TXTF bit set. So I tried clearing it by writing 16 to the IFCR register (pausing the application at a random place, from the debugger and writing the value to the IFCR register). This seems to be unblocking the peripheral as the data is being sent through, until it gets stuck again and I am able to unblock it in the same way as before.

I tried this inside a loop, clearing the SR_TXTF flag by writing 16 to the IFCR register, but that did not really solve the problem, as I was probably doing it at the wrong moment.

As a starting point it would be great if you could indicate when should I perform the steps you mentioned.

This is all I have gathered so far.

Thank you again for your assistance

[Saket_Om]

Hello @G_Anastasopoulos 

According to the cotent of SR register the Flag EOT is set signaling that the transfer is finished. 

Have you other peripheral that are configured in interrupt mode in your application? The problem can come from the interrupt priorities.