STM32H743 - SPI stops working after a while and doesn't create Clocks

[GS1]

Hi all,

I have a complex system with several STM32H743 processors, 1 Master, 6 Slave processors. The Master sequentially reads data from all Slaves via Interrupt handling.

SPI clock speed is 16 MHz, access to data reads (108 Bytes each Read) every 10 ms.

The communication runs properly for some hours but then suddenly one or more SPI ports do not send out clocks anymore - thus no further data is read.

I detected that the MASTER Bit in CFG2 register is reset in this case (which of course causes that no clocks are output)

I use MXCube code (Version 1.2) and the call to "HAL_SPI_ReceiveIT" returns "HAL_OK". But no data is received due to missing Clocks for the SPI.

Can anybody tell, what could cause the Master Bit to be reset (without calling HAL_SPI_Init or reconfiguring the SPI) ?

The other registers look ok (SPE = 1, CSTART = 1, TXTF=1, TXP=1, Interrupts are enabled).

Any help very much appreciated!

[waclawek.jan]

> what could cause the Master Bit to be reset

NSS going low, unless SSM and SSI are set.

JW

[GS1]

Hello JW,

thank you for your comment.

But: SSM and SSI are set.

GS

[GS1]

I detected the following information in the Errata of the chip:

Master data transfer stall at system clock much faster than SCK

Description

With the system clock (spi_pclk) substantially faster than SCK (spi_ker_ck divided by a prescaler), SPI/I2S master data transfer can stall upon setting the CSTART bit within one SCK cycle after the EOT event (EOT flag raise) signaling the end of the previous transfer.

Workaround

Apply one of the following measures:

• Disable then enable SPI/I2S after each EOT event.

• Upon EOT event, wait for at least one SCK cycle before setting CSTART.

• Prevent EOT events from occurring, by setting transfer size to undefined (TSIZE = 0)

and by triggering transmission exclusively by TXFIFO writes.

System clock is 400 MHz, SPI Clock is 16 MHz. So this error could be the reason.

I will try the Disable/Enable procedure and will report if this cured the problem.

[GS1]

Update:

Disable/Enable of SPI did not cure the problem. Furthermore the HAL functions already call Disable/Enable SPI.

And the problem still exists.

This morning again: The system was running the whole night with the ULINK connected and Keil Debugger running. One SPI was not working any more. It did not send clocks. When stepping throught the HAL call for receiving a new record, everything looks as normal. Leaving the function with "HAL_OK".

This time the Master-Bit was set correctly, all SPI registers were set ok - as far as I could see.

But no clocks arrived at the Slave side! (Checked with the Osci on the SPI pins).

Any ideas?

[GS1 · Accepted solution]

The solution for the problem:

Call HAL_SPI_Abort() before starting a new receive/transmit finally curred the problem.