Skip to main content
Associate III
February 8, 2024
Solved

HAL_SPI_Receive returns TIMEOUT in ThreadX and touchgfx

  • February 8, 2024
  • 11 replies
  • 5207 views

Hello.

I have created a project with STM32H7, and in the project, I have included TouchGFX and ThreadX.

I have an external memory controlled by SPI5. Everything works correctly. However, on some occasions, the function:

 

status = HAL_SPI_Receive(hspiDFW25, bufferRX, bytes_to_read, 1000);

returns TIMEOUT.

If I give higher priority to the task where the HAL_SPI_Receive function is called than to the TouchGFX task, the error occurs less frequently. However, it still persists.

Any ideas?

This topic has been closed for replies.
Best answer by fernandogamax

Hello, new tests

I have managed to make it work using HAL_SPI_recive_IT and HAL_SPI_recive_DMA.

But I can't get it to work HAL_SPI_recive.

The solution has been the priority of the interrupts. Configuring them as follows:

fernandogamax_0-1707992317631.png

I would like to know if this saturation is normal or if I am configuring something wrong?

 

 

 

11 replies

fernandogamaxAuthorBest answer
Associate III
February 15, 2024

Hello, new tests

I have managed to make it work using HAL_SPI_recive_IT and HAL_SPI_recive_DMA.

But I can't get it to work HAL_SPI_recive.

The solution has been the priority of the interrupts. Configuring them as follows:

fernandogamax_0-1707992317631.png

I would like to know if this saturation is normal or if I am configuring something wrong?

 

 

 

Bob S
Super User
February 15, 2024

> I would like to know if this saturation is normal or if I am configuring something wrong?

"normal" depends on what all you've got going on with the other interrupts and DMA operations.  The two OCTOSPI ports, LTDC and USB HS ports are all potentially high bandwidth interfaces.  I have no experience with OCTOSPI or LTDC, so I don't know what kind of load they (or their HAL drivers) put on the CPU.  FLASH and external memory wait states also impact CPU throughput, as does all the arbitration between all the different peripherals and the memory bus.

But in general, any time you are trying to handle incoming or outgoing data at a "high" data rate, DMA should be your first choice as it minimizes the number of CPU cycles needed to send/receive the data.  And for something like your SPI interface with a 4.2MHz clock can potentially  receive around 500K bytes/second. That definitely fits the "high data rate" that should use DMA.