One bit shift in SPI communication on STM32H7

1
votes

I'm working on SPI communication between two Nucleo-H743ZI boards. I'm using ST's HAL, and the SPI polling API HAL_SPI_TransmitReceive.

It's working fine until a bandwith of 12Mbits/s (SPI kernel clock at 200Mhz and prescaler 16, the CPU is always at 400Mhz) but fails above (smaller prescaler).

I want to understand since 24 or 48 Mbits/s doesn't seem much even in polling with a poor quality software.

With prescaler set to 8, I don't have SPI error like overrun or other (I checked directly in registers), however the data are not correct. looking closer to the data, I've noticed that there is only a shift of one bit.

More precisely I should receive (in hexa ): 0x30 0x31 0x32 ... And I receive 0x18 0x18 0x99...

In binary:

  • expected 0011 0000 0011 0001 0011 0010...

  • received 0001 1000 0001 1000 1001 1001...

If I shift the received bitstream to the left I get exactly the right result.

Does it ring something to you ? Could it be due to a bad configuration ?

Obviously master and slave have the same configuration regarding phase and polarity (and everything else since the source code is mostly identical).

2
stm32spi
Such a bit shift could indicate that you the SPI master or slave is not operating in the correct SPI mode. The SPI mode defines clock polarity and phase. If they aren't matching between slave and master, you can get data shifted by one bit. – Codo
You're right but as I've written, the SPI initialisation code is the same for slave and master. I just double checked, Phase and polarity are the same for both. And it's working anyway at slower frequencies. – Guillaume Petitjean
How could we guess if you don't show the code? What are the relevant GPIO register values, in particular OTYPER, OSPEEDR, PUPDR at the time of the transmission? – followed Monica to Codidact
Does the master or the slave have trouble receiving data? And it would probably be helpful if you could capture the signals with an oscilloscope and add a screenshot to the question. The problem could be at the hardware level. – Codo
@codo Good remark. Actually the slave receives correctly, the error is only at master side.Communication is full duplex. I agree about the benefit of a scope capture but I don't have one. I will try to set the slave in DMA mode, in case it is not fast enough to receive and send. – Guillaume Petitjean

2 Answers

2
votes

Check the Output timing characteristics table in the datasheet.

The binary number in the leftmost column is the value that goes in GPIO->OSPEEDR. At VDD=3.3V (That's what the Nucleo board uses), value 00 would work up to 12 MHz, that's exactly where your signal is starting to break down. Just turn it up to the maximal value, it doesn't hurt. (Well, it might overload something if you toggle lots of pins at once.)

0
votes

48mbits means 6MB per second. Even if your uC is 400MHz you have only 50 clocks per byte. It is far not enough. For the higher speeds only DMA is possible definitely not the polling especially using HAL libraries.

48MHz cablewise is not easy as well.