GPIO rise/fall time on Nucleo H7

[joeyjumpers]

I am prototyping an application on a Nucleo H7 board and I would like to use 50 MHz SPI master for performance reasons.

At lower speeds (25 MHz, for example) I am able to generate a fairly clean SPI Mclk that passes requirements, however at 50 MHz I end up with a clock signal that very much resembles a sine wave and does not meet setup / hold requirements.

I have tried various configurations of the SPI peripherals (e.g., 100 MHz master clock /2 divider, 200 MHz master clock /4 divider), various master clock sources, etc. At this point I am fairly sure that the problem I am observing is related to the GPIO characteristics of the Mclk pin.

Referencing "Table 68. Output timing characteristics" of the datasheet "Output high to low level fall time and output low to high level rise time" =~ 5ns (depends on load capacitance) @ very fast drive speed, I would expect to see a better signal here, one that reaches 3.3V (or 1.8V - I tested both!) and levels off for some time before falling edge @ 50 MHz. But obviously I don't see that.

So my questions are:

1. Am I interpreting Table 68 correctly, is it realistic to generate a nice looking 50 MHz clock from an H7 GPIO?
2. Are there some characteristics of the Nucleo board in particular (very high load capacitance?) that might make things worse?

Thank you.

[Tesla DeLorean · Accepted solution]

How are you looking at the signals?

With a scope using a 10X probe?

The SPEEDR settings in the GPIO controls the slew-rate, you should try to find the appropriate speed/load setting

On the H7 there's also an IO Compensation cell, this should be enabled in SystemClock_Config()

On the NUCLEO, check the schematic and traces. Check that the pins you're using don't have stubs or other paths / components on them.

[Pavel A.]

(2) Yes, if you connect SPI device to the Nucleo with flying wires - no chance for 50 MHz.

The best I could get with such setup was maybe 5 MHz.

On a real board the same SPI device works at ~ 30 MHz.

[AScha.3]

the pins are fast, here from H743 data:

2ns should be possible.

to see 50MHz square, need fast scope and probe - what you use here ?

see

https://community.st.com/s/question/0D53W00001vpp0NSAQ/can-make-a-50mhz-pwm-output

[AScha.3]

When your question is answered, please mark this topic as answered by choosing Select as Best for the preferred answer, as also explained here. This will help other users find that answer faster.

[joeyjumpers]

Thanks for the replies everyone. I was able to resolve the issue, two items were in need of correction:

1. My scope probe had a long path to ground, shortening it cleaned up the signals dramatically and allowed me to observe the effect of changing SPEEDR settings + IO compensation.
2. MCLK was already set to "very fast" SPEEDR (this is the default in the stm SDK when SPI alternate function is selected), setting MOSI and MISO to "very fast" allowed transfer to work successfully @ 50 MHz.

I did not change (or need to change) IO compensation regs and I was not able to find sufficient documentation about how / when to use it.

I will select Mr. DeLorean's answer as "Best", but the other two answers were helpful as well. Thank you to all.

[Piranha]

People are using external Ethernet PHY boards with RMII interface, which works exactly at 50 MHz. Most likely the typical issues are with the ground loops.

[Pavel A.]

Point taken, 10x. But ethernet has a different kind of signaling, not returning to zero? also, it is more resistant to data errors.

[Piranha]

RMII is a CMOS level logical interface from the MAC/MCU to PHY, not the physical 100BASE-TX modulated triple-level signal, which comes after the PHY.