Hello,

I am needing advice on the best practices of troubleshooting a design experiencing either EMI or ground connection issues causing interference with my data signal lines. I am attempting to communicate with an encoder using a simple bit banging method, using GPIO for the clock and data input signals. The peculiar problem I am having is that is seems to work correctly when I have a logic analyzer monitoring the CS, CLK, and DATA signals. Removing the probes of any of these results in corrupted data being read by the MCU. I have attached photos of the logic analyzer waveforms. I notice that there is still noise measured by the probe when all connections are attached, but it does not cause any issue in reading valid position data. The other graphs are when the CS, CLK, or DATA line probes are disconnected and the noise is very much an issue.

I have tried adding capacitors to ground on the lines but that was not improved performance. Any advice on how to proceed will be appreciated.

 

What is the input impedance/capacitance of the logic probes. How much cap did you try adding to the signals?

I merged the pictures. Not much help because you didn't use the same time intervals.

 

Is this I2C (TW, two wire) interface? Did you try moving your pull-up resistors (are there any?) or reducing the value? Make sure that the data lines to the probes are not ringing.

 

I am measuring 2 Mohm impedance on the input of the logic analyzer but nothing when trying to measure capacitance

What is the input impedance/capacitance of the logic probes. How much cap did you try adding to the signals?

I merged the pictures. Not much help because you didn't use the same time intervals.
View attachment 298673

Unsure how to determine the impedance of the the logic probes. The input resistance is about 2 MOhm. Some references online state the input capacitance as being around 10 pF so a few different capacitors around that value but no luck.

 

Is this I2C (TW, two wire) interface? Did you try moving your pull-up resistors (are there any?) or reducing the value? Make sure that the data lines to the probes are not ringing.

I am using GPIO pins to bit bang the CLK and read data. I have tried using the internal pull up resistors of the MCU on these pins but have not tried adding a pull up closer to the encoder connection. What value resistor would be appropriate?

 

I've tried the internal pull-ups of an AVR, but they do not supply enough current for reasonable speed (several Mbps).

Try 2.2 k pull-up resistors for starters.

Please refer to this specification for guidance. https://www.nxp.com/docs/en/user-guide/UM10204.pdf

 

Unfortunately that did not help in settling the signal lines and the only way I can measure data correctly is with the logic analyzer connected. I attempted to pull them down as well.

 

What does the addition to the logic probes add to the signals on the bus? Extra pull-up current? Enough capacitive loading the suppress ringing?

Have you looked at the bus waveforms?

 

Increasing the capacitive loading didn't help. I have looked at the bus waveforms and they are nominal. No spikes or abnormal behavior. I do receive some noise on the ground line but only when the encoder is connected. Similarly, the waveforms of the signals look correct when the encoder is disconnected.

 

Hard to say without more information. Schematic, layout, scope traces, etc. But three separate things to consider are:

• signal integrity
• timing
• protocol

Validation of signal integrity requires observation with a scope probe. The characteristics of the scope probe, your probing technique, and where you probe all are important considerations. If you don't understand these basics your observations may be misleading you.

Signal timing includes things like data setup/hold times with respect to clocks, clock frequency/period, minimum/maximum assertion times, etc. Again, these are characteristics that you have to validate through careful scope observation.

If you have validated signal integrity and timing... then you can move on to validation of signal/wire/communication protocol (whichever term you prefer). This is the sequence of multiple events to effect digital communication. I2C is an example protocol.

Going back to signal integrity... fast digital edges (fast rise times or fast fall times) particularly on clock signals are common sources of problems. There are a few things that you can do with many/most microcontrollers such as configure a GPIO pin drive strength. Reducing drive strength reduces the fast edge rates that may be causing problems.

The fast edge rates cause things like overshoot/undershoot (ringing) on the signal when it changes states (high to low, low to high). This is caused by impedance mismatches between the source (the output driver), the impedance of the signal trace on the PCB (or wire), and the impedance of the load (the input receiver). Typically, the output driver is a couple of ohms at most (near zero), the trace is 65-85 ohms (unless you have specifically designed it to be a controlled impedance trace), the digital input is very high (megaohms or essentially infinite).

You would have to look into transmission line theory to understand the effects of these impedance mismatches. There are surely many good youtube videos and articles that are easily found. But, the common solution is to include a series resistor between the output driver and the signal trace located as close as possible to the output driver. This reduces the impedance mismatch between the driver and the signal trace but also slows the fast edge rate due to the series R and the signal trace and input capacitance. So you get an RC effect on the edges of the signal (small but effective). Typical series R values range from 20 to 33 ohms for uncontrolled impedance signals.

So... start with scope observations of the signal integrity and timing. The logic analyzer is your last step to validate signal protocol.

 

Hard to say without more information. Schematic, layout, scope traces, etc. But three separate things to consider are:

• signal integrity
• timing
• protocol

Validation of signal integrity requires observation with a scope probe. The characteristics of the scope probe, your probing technique, and where you probe all are important considerations. If you don't understand these basics your observations may be misleading you.

Signal timing includes things like data setup/hold times with respect to clocks, clock frequency/period, minimum/maximum assertion times, etc. Again, these are characteristics that you have to validate through careful scope observation.

If you have validated signal integrity and timing... then you can move on to validation of signal/wire/communication protocol (whichever term you prefer). This is the sequence of multiple events to effect digital communication. I2C is an example protocol.

Going back to signal integrity... fast digital edges (fast rise times or fast fall times) particularly on clock signals are common sources of problems. There are a few things that you can do with many/most microcontrollers such as configure a GPIO pin drive strength. Reducing drive strength reduces the fast edge rates that may be causing problems.

The fast edge rates cause things like overshoot/undershoot (ringing) on the signal when it changes states (high to low, low to high). This is caused by impedance mismatches between the source (the output driver), the impedance of the signal trace on the PCB (or wire), and the impedance of the load (the input receiver). Typically, the output driver is a couple of ohms at most (near zero), the trace is 65-85 ohms (unless you have specifically designed it to be a controlled impedance trace), the digital input is very high (megaohms or essentially infinite).

You would have to look into transmission line theory to understand the effects of these impedance mismatches. There are surely many good youtube videos and articles that are easily found. But, the common solution is to include a series resistor between the output driver and the signal trace located as close as possible to the output driver. This reduces the impedance mismatch between the driver and the signal trace but also slows the fast edge rate due to the series R and the signal trace and input capacitance. So you get an RC effect on the edges of the signal (small but effective). Typical series R values range from 20 to 33 ohms for uncontrolled impedance signals.

So... start with scope observations of the signal integrity and timing. The logic analyzer is your last step to validate signal protocol.

I am having personal trouble in my life causing some delay in analyzing this further with a probe and providing snapshots, but I have attached a simplified schematic of the design. Input signals go directly to MCU pins and output signals go directly to encoder header.

There are certainly other issues that I am contending with the board that could be causing the problem. This translator is meant to be connected to a RS-485 transreceiver to communicate to an Endat 2.2 protocol encoder, but there was a flaw in the design preventing me from establishing communication to it. In order to prototype the simpler encoder, I had to cut traces to the transreceiver and use wires to connect the output of the 10 ohm resistors to the connector of the encoder.

I will have to provide snapshots of the waveform tomorrow that show the difference in integrity when the encoder is plugged into the board versus disconnected, but I did use a scope last week that didn't pick up an erratic signal when the encoder is disconnected that would indicate the cut traces being a problem, but it may be the issue when under load.

The new design is an upgrade of a proven design that uses a simpler encoder and all it requires is a voltage translator to buffer between MCU and encoder, no resistors in series with signal lines. The datasheet of this particular translator specifies that it cannot be used with I2C protocol, hence my attempt to use specifically timed gpio bit banging. I will dig more into the impendence mismatch being a potential problem that cannot operate in this work around configuration this week.

 

Unfortunately my O-scope cannot transfer snapshot of the waveforms so I have to take a picture of it. The first two phots are a sanity check that show what the CS and CLK look like when the encoder is disconnected. The third photo spotlights the major issue I seem to have when the encoder is connected. I disconnected the encoder and set the CS to high to see what value I was getting from the MCU and it gave me 3.3V as expected. I reconnected the encoder and it results in my CS turning into a sine wave. It was measured on the input side of the voltage translator while the CLK and CS lines are set high by the MCU. The CLK also turns into a sine wave when I should expect constant 3.3V. I have tried with another encoder and gotten similar waveforms so I am either missing a key component or there is another issue with the way power is being delivered to the encoder. I decided to cut the power lines to the encoder to see the waveforms when only the CS/CLK/DATA lines were connected and it removed the interference to the input CS/CLK lines.

 

This is what I see on the CS line when I do toggle it low during transmission while the encoder is not receiving power

 

Hello,

I am needing advice on the best practices of troubleshooting a design experiencing either EMI or ground connection issues causing interference with my data signal lines. I am attempting to communicate with an encoder using a simple bit banging method, using GPIO for the clock and data input signals. The peculiar problem I am having is that is seems to work correctly when I have a logic analyzer monitoring the CS, CLK, and DATA signals. Removing the probes of any of these results in corrupted data being read by the MCU. I have attached photos of the logic analyzer waveforms. I notice that there is still noise measured by the probe when all connections are attached, but it does not cause any issue in reading valid position data. The other graphs are when the CS, CLK, or DATA line probes are disconnected and the noise is very much an issue.

I have tried adding capacitors to ground on the lines but that was not improved performance. Any advice on how to proceed will be appreciated.

Yes, I've encountered this issue in an analyzer used to test the stability of a closed-loop function. It worked perfectly with the analyzer connected. It failed when it was removed. What I ended up doing was carefully placing a capacitor, in this case 100 pF, that represented the test probes I used, between the probe connecting point and the probe grounding point. The parasitic capacitance introduced by the test probes was thus restored. And it took some trial and error to get it to work.

Pity the poor technician who tries to understand why that little capacitor is in the odd place that it is...

 

Wish it were that easy in my case. The 100 pF capacitors reduced the overshoot but this is my output on the CS and CLK lines, tons of noise. The encoder is proven to be functional on a different device, but when connected to my board remains unfunctional. It operates with 5V and other peripherals that use that bus remain functional and the waveform is stable. I may try and bypass the voltage translator and operate the device with 3.3V signals instead to eliminate a potential point of failure.

 

I was able to resolve the issue by wiring the CS and CLK lines to the input side of the voltage divider. It is unclear to me why these distortions would appear on by utilizing this particular device at the speed I was attempting to communicate at and it makes me worried for the new design in the board house that is currently being made for it. I will have to pose the question to TI why I was not able to establish a clean signal. I didn't chose the part, it is part of the design of a developmental board that TI provides which I copied. I hope it works for the complete design that connects to a RS-485 transceiver which is also copied from there own design.