2024-10-28 04:56 PM
Question about HAL_SPI_TransmitReceive timeout.
Currently, a timeout occurs when calling HAL_SPI_TransmitReceive in our program. (We are the master)
What are some of the factors that cause a timeout in HAL_SPI_TransmitReceive?
Solved! Go to Solution.
2024-10-30 03:47 AM - edited 2024-10-30 03:55 AM
Same question here:
Threads merged.
Please see the Posting Tips for how to properly post source code:
@pass3master wrote:Why would a timeout occur just by changing the size?
Obviously, the larger the transfer size, the longer it will take to complete
Use an oscilloscope or logic analyser to see what is actually happening on the wires
2024-10-28 05:19 PM
Regarding the problem of timeout when performing HAL_SPI_TransmitReceive with different sizes in succession
We are handling as follows
(CS operation and SPI CLK Enable processing are omitted)
①HAL_SPI_TransmitReceive(&hspi1, data, rxbuf, 4, 1000)
HAL_SPI_TransmitReceive(&hspi1, data2, rxbuf2, 23, 1000)
For some reason, a timeout occurs in the middle of data2 transmission (4th byte).
Why does it time out? It seems that the Size setting in (1) has been taken over, but I do not know how it works.
[Supplemental] If HAL_SPI_Init is performed between ① and ②, the timeout will not occur.
2024-10-28 06:55 PM
The SPI peripheral clock isn't enabled? Timeout is shorter than the buffer length and clock speed.
Check the SPIx register content
2024-10-28 06:59 PM
Thank you for your response.
The SPI peripheral clock is enabled.
The timeout time is appropriate. Are there any other reasons that could cause a timeout?
If the SPI module crashes during SPI communication, will it cause a timeout?
2024-10-28 08:24 PM
All the source code for the library is provided, and you can always use the debugger to understand why data doesn't clock out, or clock back in.
I've got no visibility into your code, or the registers in the STM32
2024-10-28 10:56 PM
"All the source code for the library is provided, and you can always use the debugger to understand why data doesn't clock out, or clock back in.”
Indeed! You are right.
We found that the following process is executed within HAL_SPI_TransmitReceive(stm32h7xx_hal_spi.c 1594L).
How can I find out the cause of the timeout from here?
Should I check the register values?
stm32h7xx_hal_spi.c 1594L-------------------------------------------
/* Timeout management */
if ((((HAL_GetTick() - tickstart) >= Timeout) && (Timeout != HAL_MAX_DELAY)) || (Timeout == 0U))
{
/* Call standard close procedure with error check */
SPI_CloseTransfer(hspi);
SET_BIT(hspi->ErrorCode, HAL_SPI_ERROR_TIMEOUT);
hspi->State = HAL_SPI_STATE_READY;
/* Unlock the process */
__HAL_UNLOCK(hspi);
return HAL_TIMEOUT;
}
2024-10-30 03:41 AM - last edited on 2024-10-30 03:44 AM by Andrew Neil
Regarding the problem that SPI communication times out in the middle of the communication
When SPI communication is performed as shown below, a timeout occurs in the ← section.
I think that HAL_SPI_TransmitReceive just before the timeout is affected, but I don't know why.
Why would a timeout occur just by changing the size?
/* SPI_CS High */
HAL_GPIO_WritePin(GPIOG, GPIO_PIN_10, GPIO_PIN_SET);
__HAL_SPI_ENABLE(&hspi1);
/* SPI_CS Low */
HAL_GPIO_WritePin(GPIOG, GPIO_PIN_10, GPIO_PIN_RESET);
g_result = HAL_SPI_Transmit(&hspi1, spi_txdata2, 4, 1000);
__HAL_SPI_DISABLE(&hspi1);
/* SPI_CS High */
HAL_GPIO_WritePin(GPIOG, GPIO_PIN_10, GPIO_PIN_SET);
__HAL_SPI_ENABLE(&hspi1);
/* SPI_CS Low */
HAL_GPIO_WritePin(GPIOG, GPIO_PIN_10, GPIO_PIN_RESET);
g_result = HAL_SPI_Transmit(&hspi1, spi_txdata2, 20, 1000); ←
/* SPI_CS High */
HAL_GPIO_WritePin(GPIOG, GPIO_PIN_10, GPIO_PIN_SET);
2024-10-30 03:47 AM - edited 2024-10-30 03:55 AM
Same question here:
Threads merged.
Please see the Posting Tips for how to properly post source code:
@pass3master wrote:Why would a timeout occur just by changing the size?
Obviously, the larger the transfer size, the longer it will take to complete
Use an oscilloscope or logic analyser to see what is actually happening on the wires