Sometimes HAL_SPI_TxRxCpltCallback() is not getting called.

[PDhar.1]

We are using STM32G4 Series microcontroller for SPI comm. as slave with microprocessor.

For SPI TX operations sometimes we are seeing that callback function HAL_SPI_TxRxCpltCallback() is not getting called even though we are seeing that data is transmitted successfully on SPI line. Checked using logic analyzer.

Is this known issue? Any solutions for this.

Thanks in advance.

[Bob S]

Showing your code would be helpful.

Are you calling HAL_SPI_Transmit_IT() or HAL_SPI_TransmitReceive_IT()? If TX only, are you sure the TxRx callback is SUPPOSED to be called?

[PDhar.1]

We are using HAL_SPI_TransmitReceive_IT() function and then waiting for callback HAL_SPI_TxRxCpltCallback() to know that Tx/Rx is completed . This usually works, but sometimes callback does not get called and Tx gets timeout (waiting for 500ms)

if (HAL_OK
                                    != HAL_SPI_TransmitReceive_IT(
                                            &hspi2,
                                            gui8AppBufATx,
                                            gui8AppBufATxTemp,
                                            sui16BufferLength))

[PDhar.1]

Checking HAL driver code ISR routines,

SPI_TxISR_8BIT() which calls SPI_CloseRxTx_ISR() and this calls  HAL_SPI_RxCpltCallback(hspi);

Which isr to check/debug any pointers would be helpful.

[Bob S]

Is the logic analyzer image you posted from a transaction that succeeded or failed? The 2nd trace from the top looks like the clock, and the 4th from top looks like MISO. What are the top and bottom traces? Either one could be the SS. Are you using the hardware NSS feature?

My guess is either a timing issue or memory corruption in the hspi structure (low probability. Or the code knows you are using Hungarian notation and is rebelling (sorry, can't resist).

Which version of G4 HAL are you using? What are the CPU and SPI clock frequencies?

Have you checked the errata? The G47x/48x has one related to the BUSY bit, don't know if that is related to this. You would have to dive into the HAL SPI code. Might have to go through the SPI IRQ code anyway to track this down.

[PDhar.1]

The transaction is success as all the data is seen on the line.

The top one CS from master here it is microprocessor . The bottom one is ATTN line which slave drives low to send data to microprocessor.

This is HAL version 1.4 and SPI frq is 1MHz.

Will be going through ISR routines for debugging. Any pointers to debug ISRs routines will be helpful as I have not done this before.

Thanks

[Bob S]

SIngle-stepping or breakpoints in ISRs can be tricky as they change the timing and therefore (probably) the behavior.

First thing I would try is a breakpoint on whatever code you have to determines the transaction timed out. When that breakpoint is hit, look at the hspi2 structure and see what you can see. Look at state variables, counters, etc. Or dump the contents here if you don't see anything useful. Also look at the SPI registers contents.(CR1, CR2, SR).

[RENMIN]

Has this issue been resolved?

I have the same problem