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. 

[G_Anastasopoulos]

@Saket_Om 

I have plenty of other peripherals running with enabled interrupts. This is my configuration:

Most of the interrupts have equal priority, so could this be a problem?

What I am doing here is reading data from the SD card, forwarding them to the decoder over SPI, while running a GUI, so there is a lot happening. Do you believe that the issue I am seeing comes from dropping an interrupt on the SPI side?

[Saket_Om]

Hello @G_Anastasopoulos 

To check this hypothesis, you need to try running SPI lonely or make SPI interrupts priorities higher than another peripheral. 

You can also check the IT mode instead of DMA mode and check if the issue come from DMA

[G_Anastasopoulos]

Dear @Saket_Om 
Thank you very much for your assistance so far. Unfortunately testing with the IT mode is not going to provide us with any assistance as we specifically need to be using DMA in order to be able to pause and continue.

Based on your suggestions I tried a couple of things:

I tried increasing the priority value of everything else but the GPDMA channel 2 and the SPI global interrupt, without any success. I then tried to decrease the priority value for the EXTI of line 11, which is responsible for pausing and resuming DMA, also without any success.

Leaving the device overnight to get stuck, I see this state:
spi interface

and gpdma for the SPI TX

From what I understand by looking at this, the SPI device is not actually doing anything and the GPDMA has 4072 bytes that it needs to send, based on the CBR1 value, is this correct?

What exactly needs to be done at this stage in order to get the DMA going?

Does this state of the 2 peripherals perhaps helps a bit more with understanding what is the issue?

Thank you very much