Tool Selection Strategy for Debugging Communication Issues

[EVblog1]

I'm new here and I'm trying to understand how experienced engineers debug communication issues between MCUs and peripherals. For example, in a hypothetical case where an MCU is connected to an RTC module over I²C, and the date and time are not displaying correctly on an external display—how do you decide which tool (multimeter, oscilloscope, logic analyzer, or hardware debugger) to use at each stage, and why?

My current understanding is: I would first check power and continuity with a multimeter. Then, I’d use an oscilloscope  or a logic analyzer to check I2C signals . Finally, I’d use a hardware debugger to step through the code and check whether the RTC is being initialized and communicated with correctly.

I'm not just trying to learn what each tool does individually, but how and when to choose between them effectively during system-level debugging.

Could you please explain how you would approach this situation and what role each tool would play?

[zapta]

After testing with an oscilloscope that the i2C signals are 'alive' and have the expected signal levels, I would connect a logic analyzer (e.g. a salea or a clone), set the i2c decoder and examine the communication.

[hans]

An oscilloscope typically gets the most mileage even though its not the optimal tool for many jobs.

However, you can check both ends of a connection (e.g. MCU pin to sensor pin, which includes cable, PCB etc.) with the scope probe. See if the same waveforms appear on both ends. Typically you'll need somekind of activity in the system though. But it can verify continuity.

You can check signal levels of the I2C bus itself. Is the idle level at what you expect? Are the rising edges too slow (weak pull-ups/too high frequency)? Is the bus being pulled low for long duration?

Many modern scopes also have protocol decoders, so for simple protocols you could inspect what is going on. For deeper dives, use logic analyzer or debugger of your MCU. Typically its useful to have some spare GPIO as well to use as a trigger for scope/logic analyzer from your own firmware code. You can then crosscheck if the data/interrupts in your MCU correspond to whats on the actual wires.

[tggzzz]

I'm new here and I'm trying to understand how experienced engineers debug communication issues between MCUs and peripherals. For example, in a hypothetical case where an MCU is connected to an RTC module over I²C, and the date and time are not displaying correctly on an external display—how do you decide which tool (multimeter, oscilloscope, logic analyzer, or hardware debugger) to use at each stage, and why?

My current understanding is: I would first check power and continuity with a multimeter. Then, I’d use an oscilloscope  or a logic analyzer to check I2C signals . Finally, I’d use a hardware debugger to step through the code and check whether the RTC is being initialized and communicated with correctly.

I'm not just trying to learn what each tool does individually, but how and when to choose between them effectively during system-level debugging.

Could you please explain how you would approach this situation and what role each tool would play?

In order, do not proceed to N+1 until N is OK

• specify whether this is prototype or production equipment, and whether it previously worked
• check connections
• use multimeter to measure PSU for power and noise, at all major components. Repeat with scope
• use scope to verify analogue signal integrity - voltage, timing, monotonic transitions. Ensure you are using good probing technique otherwise the traces will be misleading
• use debugger and printf() statements to indicate commands being sent and responses received
• use message decoder to examine commands and responses. Scope might be sufficient for simple cases, otherwise use a protocol/message analyser

[linux-works]

yes, you need both the scope and a logic analyzer.

I had to debug some serial i/o and started with the scope, (one that can also do some level of decode), then once I saw there was data, I switched over to a logic capture device and that gives easier search and analysis.

[linux-works]

the logic analyzer I used is the $10 clone:

https://www.amazon.com/HiLetgo-Analyzer-Ferrite-Channel-Arduino/dp/B077LSG5P2

they all use the cypress chipset (at least they used to) and its compatible with some commercial software as well as open source stuff.

you get 8 logic inputs.

one trick is to use a spare gpio on your cpu and do digital write's at key points in your routine and you can see where they show up in time, on a logic trace.  gpio flipping takes no time but printf can change your timing too much, so its to be avoided in timing critical debug areas.

[Doctorandus_P]

For I2C it's always important to verify signal integrity with an oscilloscope. You can't do that by looking at source code or a logic analyzer trace. I do have a Siglent SDS 1104X-E to do this, but once signal integrity is verified, I do the rest with a Logic Analyzer. I have a few of the USD5 Saleaeae clones and use them with Sigrok / Pulseview (Gorgeous program, quite a shame it's struggling to keep it's head above the mowing field). I find the big scope probes very cumbersome to use. I like using breadboards with uC modules in DIP format (Bare crystals on breadboards are a huge reliability problem, but the small uC breakout boards work wonderfully). It's easy to use some short dupont wires between the LA and the breadboard. I also find that a big 4k PC monitor with mouse and keyboard is a much more convenient user interface for an LA then an oscilloscope screen. Zooming, scrolling is quicker, you have many more channels (16 with my Kingst LA2016, My EUR60 upgrade from the Saleaeaea clones). You can also enter signal names & labels with a normal keyboard, save and recall configurations from disk, have many more signal analyzers.

Another debugging technique I use regularly is to spit out some serial data (uart, spi, I2S, whatever peripheral is available, even bitbanging an I/O pin) and then catch that data with the logic analyzer too. This lets you build a correlation between the other signals and what your software is doing. For example, you can spit out a particular byte each time an ISR is triggered, and use different bytes for different ISR's.

You can also toggle an I/O bit when the uC is "idle". Whenever this bit stops toggling, the uC is doing "something" (such as servicing an ISR).

I'm no expert, and have not used a "real" debugger much. Stepping though code is also a very limited technique. It's very slow, and it completely disrupts timing of everything. Spitting out some bytes and catching it with a LA gives you the opportunity to trace backwards when you've found "weird behavior", and then go searching for what happened just before the fault.

With my Siglent, I can probably see the bytes of I2C fairly easily, but Sigrok / Pulseview has decoders you can stack on top of the bare I2C bytes. I once examined some low-speed USB signals this way, and the amount of information it reveals immediately is amazing. It shows T-states, keep alive packets, addressing, where data is in packets, checksums and whether they are good or not and much more then I can recall right now.