STM32H723VG SPI TransmitReceive sometimes works and sometimes does not, based on Delay length

[Daniel_]

Hello,

I have developed my own board using the STM32H723VG and two equal sensors connected separately via SPI1 and SPI2.

I have underclocked the MCU to 300MHz. The SPI clock is 48MHz while the communication frequency for both sensors is 24MHz. As CS I am using a manually toggeled pin. I am using the HAL and the STM32CubeIDE. 

For setting the initial registers of the sensors Iam using the blocking SPI TransmitReceive function. While reading a known register value from the sensor 1 which is connected via SPI1 I have seen that sometimes the used SPI HAL function does not return the expected value but returns HAL_OK. Instead of the expected Value (71) i get a 0.

So far I have discovered in a test code that the issue occures after using a delay longer than 145ms.

I dont know why a HAL_Delay or just anything else which blocks an SPI transaction for longer than 145ms should result in an SPI communication error. I doubt that my issue has something to do with the custom board since it does obviously work (with a delay less than 145ms).

I have my test program attached. Does anyone know how I could solve my problem or how I could try investigate it further?

[AScha.3]

Hi,

I dont understand : SPI clock is  -- communication frequency  is 24MHz -> on spi also ? or what at 24M ?

+ Which sensor ?

+ underclocked the MCU to 300MHz  --- thats a great new definition for a cpu at 300M !!  🙂 🙂

+ > which blocks an SPI transaction for longer than 145ms

I cannot imagine, why the delay should change the data - except, the unknown sensors going crazy...

[MNapi]

you have to check which mode works better, I had the same problems IT mode might be better solution or DMA

instead of TransmitReceive

I use first Transmit then Receive with small delay between. I had also problems with TransmitReceive and proper timing.

blocking SPI mode might not be good idea if you have some interrupts running already.

[TDK]

What sensor? Critical part of the problem statement here.

I dont know why a HAL_Delay or just anything else which blocks an SPI transaction for longer than 145ms should result in an SPI communication error.

Sounds like it may be going into a low power mode after 145ms after which it takes some time to start back up and respond. Complete guess, but it would certainly track with the symptoms.

[Tesla DeLorean]

Get a logic analyzer on the pins and see what's happening, vs the expectations in the sensor's data sheets.

Particularly how CS is placed with respect to how the data gets clocked on the wire, and manages the end of transmission, and inter-transmission dwell times.

[Daniel_]

Sorry that was an missclick. It is not the accepted solution. Is it possible to change it afterwards?

My comment was:

Hello,

thank you for your answere.

- There is an SPI peripheral clock which is generated by an PLL. The communication speed is divided down from  that clock. I have mentioned this clock because the errata states that issues could occure if those frequencys are to fare apart. No values are mentioned. I have already reduced that SPI peripheral clock.

- The sensor is the ICM-42688-P. I have already worked with that sensor. After finding the right SPI mode I never had issues.

- underclocked or clocked down from 550MHz.

- Me too. Thats why I made this post.

[Daniel_]

Hello,

thank you for your comment and idea. I will test using interupt and dma. Those modes would also be my prefered modes after set up of the sensor.

[Daniel_]

Hello,

thank you for your comment and idea.

The sensor is the ICM-42688-P. I have already worked with that sensor using the same MCU but used just SPI2 for one sensor. I had no issues with just one sensor.

I will have look whether SPI1 has such a feature or similar stuff.

[Daniel_ · Accepted solution]

Hello,

after TDKs response I found a workaround for the issue. I simple send one dummy byte while I havent toggled the CS pin, before sending my data, to "wake" the spi peripheral. Now it works. It is good enough for sensor setup.

Thanks everyone for your comments.