STM32H753 SPI1 Tx bitshifts SPI2 Rx

[pessimisticninja]

Hello,

I have been working on a project recently that has me using the SPI1 and 2 peripherals to perform conversion between a non-standard serial format and TCP/IP. I have SPI 1 set up as a transmit-only master which takes data received via TCP/IP and sends it to another device using HAL_SPI_Transmit_DMA. This works fine by itself.

I also have SPI2 set up as an rx-only slave. This receives incoming variable length serial data from another device that has a head and tail sequence to identify each packet. These come in very slowly at 64khz, and are only sent once every 200ms. A tim2 interrupt triggers a scan of the circular buffer they are received into, and if a header/tail is found then the SPI is halted, pointed at the other of two buffers, and restarted, and the rxed packed is DMAed out into memory. This also works fine by itself.

My problem is that calling HAL_SPI1_Transmit_DMA causes the data received by SPI2 to be bitshifted right anywhere from 1-8 bits, so the head/tail sequence cannot be detected. Occasionally the Rx will begin working again as the bitshift becomes byte-aligned again, but is quickly shifted again.

The same behavior happens regardless of if I use HAL_SPI1_Transmit_DMA, HAL_SPI1_Transmit_IT, or HAL_SPI1_Transmit. The two peripherals are not sharing pins or using the same DMA1 stream.

The strange thing is that I have a similar project on the exact same chip that uses the same SPI1 master/SPI2 slave setup, minus the complicated scanning since all the data it receives is the same size. This does not have the same bitshifting issue, and the code handling SPI1 is exactly the same.

Any advice that can be provided would be appreciated, just wondering if anyone else had experienced something like this before.

[TDK · Accepted solution]

This happens if the two are out of sync.

Use a CS pin to synchronize transfers with a pullup so idle state is high.

[pessimisticninja]

Yeah I figured it was something of the sort - unfortunately I can't use CS, as the device it is connected with doesn't have a CS line, it just spits out variable length packets and a clock at 64khz.

Frustratingly, it works with my simulated version of the device if I send data to SPI2 at ~500khz, but the device I am using only outputs at 64khz.

[TDK]

If it's drifting in and out of sync, that suggests there are additional pulses on the clock line that you are not expecting. That's really the only explanation. The SPI peripheral just acts as a shift register. These additional clocks can be from noise or from the CLK line not being driven properly.

[pessimisticninja]

Yep, was entirely a problem with my wiring and not the board, I put an RC filter on the clock line and now have no bitshift issues. Thanks for pointing me in the right direction.