STM32: finally data sampling delay option for SPI master has arrived!

[Karel]

- STM32 SPI peripheral has a coarse, limited range of operating frequencies to choose from (HCLK / n)

True for most of the older mcu's but the more modern ones (STM32U5xx, STM32H5xx) have 3 PLL's and
you can configure one of the PLL's just for the SPI peripheral. As a result you can setup almost any spi clock frequency.

[asmi]

True for most of the older mcu's but the more modern ones (STM32U5xx, STM32H5xx) have 3 PLL's and
you can configure one of the PLL's just for the SPI peripheral. As a result you can setup almost any spi clock frequency.

That doesn't change the fact that SPI peripherals were never designed for high-speed operation, and so complaining about it is like complaining that Arduino Uno doesn't have 10G Ethernet connectivity.

[NorthGuy]

In my experience the limitations are usually:

- device has a maximum specified operating frequency (SCLK max)
- STM32 SPI peripheral has a coarse, limited range of operating frequencies to choose from (HCLK / n)

Pick the highest frequency available that's below the maximum for the device, and that's the best you're going to get ...

This approach is very mechanical. You can do better than this.

Take for example the chip from the OP post: STM32H562.

1. Max Frequency. Let's look at the specs in the datasheet. Table 115. SPIO Characteristics. We're interested in "Master receiver mode" and "Master transmitter mode". The frequency depends on voltage. At 3.3V, it is "135/3" which is 45 MHz. Should we really stop here and settle for 45 MHz? Not really.

2. Where this number comes from? It depends on voltage, so the speed is limited by pins. The comments for table 115 say that these numbers are for OSPEED = 11 and 30 pF load. If we look at pin timing in table 63, the pin is capable of toggling at 140 MHz in such conditions, roughly the same as 135 MHz in the SPI table. But this table also say that if we lower capacitance to 10 pF then the pin can toggle at 200 MHz. As our capacitance is likely to be even less than 10 pF, we can increase our speed accordingly. Instead of 135/3, we'll use 200/3 which is 66 MHz. It's better already. Should we stop here. No.

3. Why do they divide it by 3? SPI clock changes twice during the clock - goes up once then down once. Toggling the pin at 135 Mtoggles/sec will yield 135/2 = 67 MHz clock, not 135/3 = 45 MHz/ Why the hell do they divided it by 3? The only explanation is that the duty cycle of the clock is not 50%, but 33%. The clock is high for 1 time unit then down for 2 time units. Or 66%. To produce such pattern, you need a pin capable of switching 3 times faster than the clock speed. Hence they divided by 3.

4. Where this weird 33% duty cycle clock may come from? Looking at the SPI timing you can bypass the divider by setting BPASS bit in the SPI_CFG1 register. In this case the clock given by RCC to the SPI module goes directly to the SPI's SCK pin. Could this clock have 33% or 66% duty cycle? In a matter of fact, yes. It is typically derived from PLL where it may be obtained by dividing VCO by 3 which cannot produce 50% duty cycle, only 33% or 66%. Since the specs always represent the worst case. They divided by 3 because the clock might've been derived from PLL and have 33% duty cycle.

5. Can we avoid 33% duty cycle clocks. Of course. We can create a designated PLL for SPI where we would divide by 4 or other even number, or we can use pre-scaler. This will make a 50% duty cycle clock. If we use such clock in the SPI module, we need to divide by 2, not by 3. So, instead of 135/3 = 45 MHz we get 200/2 = 100 MHz. That is how fast we can make SPI run if we need to.

6. At 100 MHz the clock cycle is 10 ns, so even with late sampling 10 ns minus 3.5 ns setup time minus 1 ns for jitter, we have only 5 ns for the round trip delay. This is tough but may work.

 

[dukelec]

I previously designed an SPI slave with the assumption that most SPI masters did not support configurable delays.
So I added a mechanism on the slave side to output SDO data slightly ahead of time to compensate for the timing delay.

The explanation and Verilog code are available here:
https://blog.d-l.io/spi-delay-compensation

STM32 SPI masters now support configurable delays. If the timing margin is still insufficient, the slave can also consider enabling early SDO output.
However, many SPI slave devices do not support this feature.