STM32 gotchas
137. Communication errors in prototype on breadboard/with flying leads - on importance of signal integrity and proper ground/return

A popular prototyping technique, especially among hobbyists, is to use development boards such as Nucleo or Disco, which have brought out mcu pins onto pin headers, and connect them to peripheral circuits (often mounted on similar development boards with pin headers) using flying leads. Sometimes a breadboard is also used as a basis for such prototype circuit.

Sometimes users complain of surprising/spurious errors in communication with the connected peripheral. In extreme situations, these problems occur also when the circuit is designed on a PCB.

Often, the common denominator to these errors is improper signal ground/return, less commonly other problems with signal integrity (crosstalk/interference). Users are usually not aware of the source of problem, and they often expect (not unreasonably) the cause of it being error in software.

While using the concept of ground as a single reference potential is a technique which simplifies understanding and thus design of circuits a lot, at the same time it is also one of the most common source of "second order" errors as described. Ground interconnections in real world have nonzero impedance (in both its real and imaginary part), thus any current flowing through them results in voltage (potential) difference, exactly as Georg Ohm ruled. Long wires, multiple and often poor quality or worn out connectors increase the impedance, while high currents and conducting currents from several sources through a single interconnection contribute to the current-part of equation.

A good common practice (besides liberal application of decoupling capacitances) is to use as short interconnections as possible, and to have a dedicated ground/return wire for each signal wire (or at least for a small group of them), routed next to the signals. Ideally returns should be routed between signals, or twisted together with individual signals, to provide shielding, i.e. decrease mutual capacitive couplig between the signals.

Also note, that long interconnections tend to have relatively high imaginary component of the impedance, in other words, they are troublesome with high frequency signals. Also note, that the "high-frequency-ness" of digital signals is not given by their digital repetition rate, but rather, by the slew rate of the edges, which in STM32 is given by setting of the respective GPIO_OSPEEDR register. In other words, never use higher signal "speed" than necessary.

While improper ground/return influences all signals, with interference it's slightly different: a signal is more prone to interference if it's source is of relatively high impedance. This is one of the reasons why we see relatively more complaints of this kind with I2C connections, as impedance of I2C signals (in the "recessive state) is given by the pullup, which is usually in the order of kiloohms, rather than impedance of an output driver, which is usually in the order of ohms (this is compounded with the unfortunate fact that I2C, while conceptually simple, is relatively hard to get right in all its details, and errors in both hardware and software are far from being rare).

Another (and maybe extreme) example of a quite often used high impedance circuit is the LSE crystal oscillator, which while it's probably never brought out of a single PCB, may be too easily influenced by improperly routed grounds and high current high frequency/slew-rate signals routed at its vicinity.

Whatever the source of faulty signals is, some communication protocols are inherently less prone to errors than others. Namely, UART with its self-clocking and multiple-sampling principle is far less vulnerable to "random noise" than say SPI, where a single spike on clock throws the whole communication astray. However, this also goes hand-in-hand with decreased maximum data rate. I2C occupies a middle ground here, as there are both analog and digital filters on its receiver; however, as is the usual case with I2C, it takes a relatively high understanding of the underlying principles and thorough reading of the manual to properly and fully employ all the benefits these features provide while avoiding all the pitfalls at the same time.

A random selection of related threads on STM32 forum: here, here, here.