STM32H743xI/G, STM32H753xI device errata and ST HAL implementation?

[George Small]

Hi All,

I've been having issues with unreliable SPI transmission on an NUCLEO-H753ZI using ST H7 HAL HAL_SPI_TransmitReceive() talking to an ICM-42688-P IMU over SPI1 at 1 to 12 MHz clocks, with H753ZI RCC set up at 400MHz CPU clock and a 25 MHz SPI1,2,3 peripheral clock.  SPI is set up for software controlled CS line to handle some specified ICM SPI timing hold time needs.

I came across a few forum posts discussing issues with SPI EOT flag timing causing frame truncations, such as "STM32H743 does not set EOT-Bit when SCK is to high" [link here] that led me to the device errata sheet [here]. 

In the errata sheet (ES0392 - Rev 13) I find "2.22.6 Truncation of SPI output signals after EOT event" I find:

With fast software execution (high PCLK frequency) and slow SPI (low SCK frequency), the SPI disable occurring
too fast may result in truncating the SPI output...

Workaround
Apply one of the following measures or their combination:
• Add a delay between the EOT event and SPI disable action.
• Decrease the ratio between PCLK and SCK frequencies.t signals...

It is unclear to me what are considered fast/high (PCLK) and slow/low frequencies (this really should be a quantified item in an official errata sheet) but I am thing 25 MHz PCLK is not really a high frequency, and going lower is not really an option.

From this I'm thinking a delay (one SPI clock period?  again - how should I determine a delay length?) is required between the EOT event and SPI disable action to properly address the known errata.

Studying the STM32H7 HAL's blocking HAL_SPI_TransmitReceive() code [link] I can find no sign of an added delay before __HAL_SPI_DISABLE() (which occurs in called function SPI_CloseTransfer() [ink].

This now has me wondering, does the ST H7 HAL not take the device errata into account for SPI transfers?  This is my conclusion so far, meaning I need to roll my own HAL_SPI_TransmitReceive for what in the end seems to be a fairly standard HAL library use case.

Am I getting this all correct?  There is much conflicting info on this issue on internet searches, including on this forum.

I am hoping to find an authoritative answer before I implement what feels like somewhat of a hack work around against a poorly written and quantified device errata item.

Best Regards,

George 

[Pavel A.]

Have you considered to leave the SPI permanently enabled rather than auto-disable? Then this issue should not occur at all. Find this bit in the SPI settings.

[George Small]

Thanks for the reply.

Yes this was considered, we are using SPI transaction enable/disable to address another SPI issue in the device errata:

2.22.2 "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 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 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.

From all this it looks like if we add a delay of at least one SCK cycle after EOT event we can just leave the SPI enabled as you suggest.

It appears that we need to create our own routines with delays added to address the errata for this common use case (SPI Master, SW driven NSS/CS, fairly standard clock frequencies).

[Saket_Om]

Hello @George Small 

In Full Duplex or Rx Only modes, this problem does not occur because the HAL waits to receive the last bit before closing the connection (disabling SPI). This ensures that the communication is completed correctly before the SPI peripheral is disabled.

Additionally, for the "transmit use case," there is more margin in the HAL implementation. This is because there are some function calls that occur before the SPI is disabled.

Did you try with polarity high; 2nd edge configuration?