I'm looking at an SPI signal generated by a test app running in a loop.

Take a look at this:



Look at D4, this is the MISO signal coming into the Nucleo F446RE board from an attached nRF24L01.

The value we read - 0E - is correct and is what I expect and is what I see in the debugger if I look, but notice the short low spike, occurring just after the 7th clock pulse.

If I "zoom in" I can see the pulse is about 7 nS:



Far to short it seems to be a legitimate aspect of SPI and far too short to impact the value we receive (0E) but that kind of thing can surely be a risk, it could have unanticipated consequences in certain situations or designs, couldn't it?

Is this common with SPI though? is it harmless because it falls within "tolerances" and so on? If I adjust the code so that that specific byte occurs in a different order, I can see that it seems to be specific to the case where the MCU sends a 0D.

It seems to be that case that it occurs whenever MOSI goes low at the same instant a clock pulse goes low, when these occur at the same time (or close to) we see the glitch on the MISO signal...

This is the SPI init code by the way.

 

Look at the signal with a analog scope input. It's likely just a ring induced spike caused by transmission line reflections . That's why we clock data in the middle of the data pulse, not at the edges.

 

Look at the signal with a analog scope input. It's likely just a ring induced spike caused by transmission line reflections . That's why we clock data in the middle of the data pulse, not at the edges.
View attachment 279542

I think I "fixed" it, just by tweaking things, the code I originally copied might have been written in haste - but changing this line to a "speed" of GPIO_SPEED_MEDIUM makes the glitch disappear! What you say makes sense but the clock and MOSI pins are totally controlled by the STM32F446RE device, aren't they? why would their hardware allow the clock and MOSI signals to coincide that way?

 

A common countermeasure to transmission line reflection glitches at the device receiving the signal is to use serial damping resistors.
https://www.ti.com/lit/an/scba012a/scba012a.pdf?ts=1667051777775


Long random wires with a fairly fast clock rate on the yellow trace below.


The purple trace is the same signal after the damping resistor R3 to the LCD MOSI input. The highest frequency components of the ring are reduced.

 

I think I "fixed" it, just by tweaking things, the code I originally copied might have been written in haste - but changing this line to a "speed" of GPIO_SPEED_MEDIUM makes the glitch disappear! What you say makes sense but the clock and MOSI pins are totally controlled by the STM32F446RE device, aren't they? why would their hardware allow the clock and MOSI signals to coincide that way?

With GPIO_SPEED_MEDIUM you slowed (that works with slower clocked signals) the rise time of the edges reducing the ringing and induced voltages from that ringing. There are garbage times and valid times in clocked signals and logic, it's the nature of the beast that's used to our advantage.
https://en.wikipedia.org/wiki/Sequential_logic

The overlapping edges and possible signal integrity issues usually don't matter unless the effects overlap into the valid times.

 

With GPIO_SPEED_MEDIUM you slowed (that works with slower clocked signals) the rise time of the edges reducing the ringing and induced voltages from that ringing. There are garbage times and valid times in clocked signals and logic, it's the nature of the beast that's used to our advantage.
https://en.wikipedia.org/wiki/Sequential_logic

The overlapping edges and possible signal integrity issues usually don't matter unless the effects overlap into the valid times.

OK let me look at these spikes in analog mode...

 

The spike should not be a problem as it occurs at the wrong edge of the spi clock you show,
and the data is sampled on the clock edge,
SPI has 4 options , as to the phase of the clock and the data sent and received.

The ringing you see on the scope, is caused by the terrible earth to the probe you have,
to probe a high speed edge,
you need to use that small clip that came with the probe, that in 90 % of the labs I see, is lost.

https://www.analog.com/en/technical-articles/short-ground-leads-make-better-scope-photos.html

https://www.digikey.co.uk/en/produc...GxFkfdybeTfr5eodfhywFxwm7OuLGb30aAusoEALw_wcB

 

Something else I notice, after the clock "burst" is over, the state of the MISO and MOSI pins seems to remain at whatever value they were after the last clock pulse. They stay at those values until the next clock burst begins and then fluctuate as expected for the data being transferred, then once again after the eight clock pulses, they again simply remain at whatever value they were.

This sounds OK to me - after all it is only their values that the clock period sampling time that matters, but is that right? is what I'm seeing normal? I kind of expected after each transfer that the MISO and MOSI would go low (or perhaps hi) and not just remain a their most recent values...

 

The spike should not be a problem as it occurs at the wrong edge of the spi clock you show,
and the data is sampled on the clock edge,
SPI has 4 options , as to the phase of the clock and the data sent and received.

The ringing you see on the scope, is caused by the terrible earth to the probe you have,
to probe a high speed edge,
you need to use that small clip that came with the probe, that in 90 % of the labs I see, is lost.

https://www.analog.com/en/technical-articles/short-ground-leads-make-better-scope-photos.html

https://www.digikey.co.uk/en/products/detail/cal-test-electronics/CT3668/5029188?utm_adgroup=General&utm_source=google&utm_medium=cpc&utm_campaign=PMax: Smart Shopping_Product_Zombie SKUs&utm_term=&productid=5029188&gclid=Cj0KCQjwnvOaBhDTARIsAJf8eVP2d8jfDniWujnEiD1LlHaGxFkfdybeTfr5eodfhywFxwm7OuLGb30aAusoEALw_wcB

Yes, the spikes seem to be irrelevant, the values sent and received seem rock solid. But I was just wondering about them as I suspect (I'm no professional but did study electronics and telecommunications for two years back in the early 1980s) such rapid spikes could lead to trouble in some situations, possibly trouble that's hard to track down.

 

Something I appreciate right away with these MCUs, is that there is a great sensitivity to even minor code changes. I'm a professional and very experienced software engineer but not with embedded stuff. Of course small changes can and do sometimes have a drastic impact on software's behavior, but its an order of magnitude greater with these MCUs.

Git is my friend hugely with these, frequent commits enable me to rapidly get back to a stable point, but I must commit more often that is typical for me.

It is fascinating though!

 

Something else I notice, after the clock "burst" is over, the state of the MISO and MOSI pins seems to remain at whatever value they were after the last clock pulse. They stay at those values until the next clock burst begins and then fluctuate as expected for the data being transferred, then once again after the eight clock pulses, they again simply remain at whatever value they were.

This sounds OK to me - after all it is only their values that the clock period sampling time that matters, but is that right? is what I'm seeing normal? I kind of expected after each transfer that the MISO and MOSI would go low (or perhaps hi) and not just remain a their most recent values...

Remember, MISO and MOSI output is a 1-bit output from a serial shift register. What you are seeing is the last bit that was sent. There is no reason for the bit to return to an "idle" state. This is not UART serial data.

 

Yes, the spikes seem to be irrelevant, the values sent and received seem rock solid. But I was just wondering about them as I suspect (I'm no professional but did study electronics and telecommunications for two years back in the early 1980s) such rapid spikes could lead to trouble in some situations, possibly trouble that's hard to track down.

But the ripple you see , the over shoot undershoot,
is probably not real,

The scope shows the voltage difference between its ground ref and its signal tip,
Your long ground lead on the probe as its reference, is such that the tip is not receiving a good reference,
fine at low frequency, but the rising / falling edge ha lots of high frequency energy ( Fourier )
and the inductance of the long earth lead on the probe stops that high frequency
you need to use the short earth clips as shown

Also,
as per @MrChips
The SPI "spec" is "ambiguous" on the data levels when chips select is not active,
"most" systems set the MOSI pin high impedance ( Tri State ) at the end of a transfer,
but a lot don't, and just leave MOSI as is at the end of the transfer,

 

But the ripple you see , the over shoot undershoot,
is probably not real,

The scope shows the voltage difference between its ground ref and its signal tip,
Your long ground lead on the probe as its reference, is such that the tip is not receiving a good reference,
fine at low frequency, but the rising / falling edge ha lots of high frequency energy ( Fourier )
and the inductance of the long earth lead on the probe stops that high frequency
you need to use the short earth clips as shown

Also,
as per @MrChips
The SPI "spec" is "ambiguous" on the data levels when chips select is not active,
"most" systems set the MOSI pin high impedance ( Tri State ) at the end of a transfer,
but a lot don't, and just leave MOSI as is at the end of the transfer,

Just FYI here is the way the thing is wired up just now



That ribbon cable connect to the SLA1016, which in turn plugs into the scope front, so no scope leads (in the conventional sense) are involved here.



Are you saying that these fine wires and connectors need to be considered here?

 

Just FYI here is the way the thing is wired up just now

View attachment 279572

That ribbon cable connect to the SLA1016, which in turn plugs into the scope front, so no scope leads (in the conventional sense) are involved here.

View attachment 279573

Are you saying that these fine wires and connectors need to be considered here?

You showed the scope probe version
which is what the links were about

What you are showing,
is the logic analyser probe
which was your first trace

Logic analyser probes , suffer the same problem,
they are a bunch of digital comparators,
they need a good reference, you have extended the ground wire,
thus degrading the reference ability ,
and showing the glitch where there is probably not one,

You did right using the analog probe,
but you nee to use the good earth on the analog scope probe,
once you have proved its a real or false glitch, then you can move forward.