SSI Slave on a STM32H743 via SPI

[Ray91]

Hello,

I must implement a SSI (Synchronous Serial Interface) to output a measured value. As SSI in principle is just a bitstream which is clocked out with the serial clock, I wanted to use a SPI in slave mode, as the clock comes from the SSI master.

This works in principle, but from time to time I get a bit shift and the received data is delayed by one bit, which results in a division by two.

Checking the SSI data clock, I didn't find an expected unstable clock with additional edges but from time to time the SSI master makes a pause after the first falling edge before it starts clocking. Could it be that this pause disturbes the SPI interface? I would have expected, that the SPI in slave mode only checks the clock edges and that the time between the clock edges isn't that critical?

[TDK]

A pause or delay on the SCK line is fine, in general and shouldn't cause issues. It's not a violation of any sort of spec. The SPI peripheral on the STM32 certainly can handle this fine.

Likely you'll have to dig into the code details to figure out where the bug is.

[Andrew Neil]

---

@Ray91 wrote:

---

Which one is the clock ?

[Ray91]

Both - the upper is the regular clock and in very rare cases it looks like the lower one.

I made some oscillograms - sorry for the bad pictures, but my old tek has no USB to copy the data and I don't have access to a datalogger.

Most times data is transfereed correct, but from time to time, there is simple a shift in the data (pics in the middle) - for me the clock and data look clean with no glitches, where I would expect the circuit to see two edges.

In very rare cases I could see the pause in front of the clock packet.

The SPI is configured as slave with a data width of 25bit. As the SSI does not have a slave slect signal, I connected the clock to another I/O pin and check the clock edges via EXTI and then I reset a counter which runs in a timer. When the SSI clock stops the counter is not reset and after about 100ns the program then stops the SPI, writes new data to the tx register and re-enables the SPI. Then the routine waits for SSI clocks again - as the SSI reads out the data every 10ms I would not expect any timing problems here. The SPI runs with a clock of 30Mhz from PLL2, so it should - in my opinion - also not be a timing problem.

What else could cause this offset in the data transfer?

[Ray91]

Hello,

OK - but what could cause the offet / shift? I made some oscillograms and described how the program works in my answer to Andrew below.

[Andrew Neil]

---

@Ray91 wrote:

Both - the upper is the regular clock and in very rare cases it looks like the lower one.

---

I see.

As @TDK suggests, SPI looks at the edges - so the actual timing shouldn't matter

(so long as it doesn't exceed the maximum limit)

[Ray91]

Hello,

as you both wrote - and I also expected, that there should be no problem with a pause at the start, as the SPI core should only check the clock edges, I looked at the code again.

My solution was to deactivate the SPI, write a new value and then to re-enable the SPI - without a pause.

I changed that, in adding a pause between the deactivation and the other two steps. Now the data transfer seems to be stable without bit shifts.

thanks

Ray

[TDK]

Program bugs cause issues. Not being ready to send data when SCK starts causes issues.

[Ray91]

Hello,

I disabled, wrote data to the tx-reg and enabled the SPI without pause.

Seems that the SPI needs some time, because after inserting a pause between disable and write to the tx reg the bit shift does not happen anymore.

[TDK]

There is no need to disable the SPI here. It will cause a bit shift if a clock comes in while the peripheral is disabled.