I had a sensor on an I2C bus that worked perfectly until it did not, intermittently, with no pattern I could find. I had been debugging it the only way I knew how, which is to say by adding print statements to the microcontroller, changing one thing, and squinting at serial output trying to infer what two wires were doing from the wrong end of the conversation. After about the third week of this I gave in and bought a logic analyser, and the problem was visible inside ten minutes. I am writing this mostly so that someone else stops guessing sooner than I did.
The thing about a bus is you cannot see it
That is the whole problem. SDA and SCL are two wires carrying a precisely timed conversation, and from the firmware side you only ever see your half of it. When a transaction fails you have no idea whether your controller sent the wrong thing, the device never acknowledged, the clock was being stretched, or the timing was marginal. You are debugging a dialogue while only able to hear one speaker, and badly at that.
A logic analyser fixes this by being the impartial third party. You clip its probes onto the bus, it samples the voltage on each line thousands or millions of times a second, and it shows you exactly what both lines did, together, on a timeline. Suddenly the conversation is right there in front of you.
You do not need to spend much
This is the part that genuinely surprised me. There is a category of cheap logic analyser, the clones of the old Saleae Logic 8, that you can buy for the price of a takeaway. Eight channels, tens of megasamples per second, more than enough for an I2C bus running at 100 or 400 kHz. The hardware is a small box with a row of probe wires and a USB lead. I expected something this cheap to be a toy. It is not. For the slow digital buses that make up most hobby electronics it is completely adequate.
The software is where it gets good, and it is free: sigrok, with its GUI PulseView. You capture a window of samples, you see the raw high-and-low waveforms of each channel, and then comes the part that turns it from an oscilloscope-for-the-poor into something genuinely powerful.
Protocol decoders are the actual magic
Raw waveforms are nice but reading I2C off a wiggling line by eye is a party trick, not a debugging method. What you want is for the tool to read the protocol for you, and sigrok has a stack of protocol decoders that do exactly that.
You tell PulseView which channel is SDA and which is SCL, add the I2C decoder, and it overlays the waveform with the decoded transaction: the start condition, the seven-bit address, the read or write bit, every data byte, and crucially every acknowledge and not-acknowledge. The bus stops being a pair of squiggles and becomes a transcript:
START
Address write: 0x48
ACK
Data write: 0x01
ACK
START (repeated)
Address read: 0x48
ACK
Data read: 0xFF
NACK
STOP
If you have ever stared at a sensor that "just stops responding", reading that transcript for the first time is a small revelation. You can see, byte by byte, exactly where the conversation breaks.
What it actually was
In my case the transcript told the story immediately. Most of the time the device acknowledged its address and the read went through cleanly. But on the failing transactions the address byte went out and there was no ACK, the device simply was not answering. That ruled out half my theories on the spot: my controller was behaving, the bus levels were fine, the timing was within spec. The device itself was intermittently not present.
That pointed me at power, and sure enough the sensor was browning out under a load spike elsewhere on the board, dropping just long enough to miss a transaction and recover before I could ever catch it from firmware. A bit of decoupling capacitance across its supply and the NACKs vanished. Three weeks of guessing, solved by being able to see that one missing acknowledge.
The lesson is about visibility, not the tool
I could dress this up as a review of cheap test gear, but the real point is more general. A huge amount of hardware debugging is slow purely because the thing you need to understand is invisible, and you waste days inferring it indirectly when a tool could just show you. The logic analyser did not make me cleverer. It made the bus observable, and an observable problem is usually a solved problem.
If you do any embedded or hobby electronics and you have been getting by with print statements and hope, as I was, spend the small amount of money. The first time PulseView decodes a transaction that you have been blind to for weeks, you will wonder why you waited. I certainly did.