For years my approach to a misbehaving serial bus was to stare at the datasheet, change one thing, and reflash. It is a slow way to be wrong repeatedly. An I2C sensor that returned nothing could be a wiring fault, the wrong address, a missing pull-up, a clock too fast for the device, or a bug in my code, and from the host side every one of those looks identical: the read just fails.
This week I finally bought one of those eight-channel logic analysers, the little blue clone that everybody has, the one that shows up under sigrok as a Saleae-compatible. It cost less than a decent meal out. I should have done it years ago.
The workflow is embarrassingly simple. Clip the probes onto SDA, SCL and ground, run pulseview, set the sample rate high enough to comfortably oversample the clock, and hit capture. You get the raw wiggles, which are mildly interesting, and then you add an I2C protocol decoder on top and suddenly the screen is showing you START, the address byte, the ACK or NACK, the data, and STOP. It decodes the bus into the same words the datasheet uses.
My actual problem turned out to be exactly the sort of thing you cannot deduce from the host. The address byte was going out fine, but the device was answering with a NACK every single time. No ACK, no data, just a flat refusal. That immediately ruled out my code, because the device was clearly hearing the address and choosing not to respond, which meant it was the wrong address.
I had been shifting the 7-bit address into the 8-bit slot myself in addition to the library doing it, so the device was being addressed one bit off and quite reasonably ignoring me. Seeing the NACK on the decoder is what made it obvious. From the host I would have spent another evening assuming a hardware fault and reseating jumper wires.
The other thing it cured was my fear of clock stretching, which I had read about and never seen. Now I can watch a slow sensor hold SCL low to buy itself time, and confirm my master actually waits for it rather than charging ahead. It moves a whole category of "I think it does this" into "I watched it do this".
It is not an oscilloscope. It tells you nothing about voltage levels, ringing, or analogue noise, and for anything where the signal integrity itself is suspect you still want a scope. But for digital protocol work, for the question "what is actually on this bus", a cheap logic analyser and an afternoon with the protocol decoders has changed how I debug entirely. The guessing has mostly stopped, and the soldering iron gets switched off a lot earlier.