Ramblings of an aging IT geek
← Ramblings of an aging IT geek
hardware

the logic analyser, or finally seeing what the bus was doing

How a cheap eight-channel logic analyser turned a week of guesswork on an I2C bus into ten minutes of certainty.

A soldering iron and a circuit board on a workbench

I spent the best part of a week last month trying to get a sensor talking to a microcontroller over I2C, and getting nothing back. No ACK, no data, just a flat read that returned the same default value every time. I checked the wiring four times. I rewrote the driver twice. I added the pull-up resistors I had forgotten, then the correct pull-up resistors. Nothing. I was reduced to changing one thing at a time and praying, which is not engineering, it is gambling with extra steps.

What I had been doing the whole time was debugging blind. I could see the code on one side and the silence on the other, and in between was a bus I was simply guessing about. So I finally bought the cheap thing I had been putting off for years: an eight-channel logic analyser, the little blue clone that costs about a tenner and shows up as a generic device the open-source software recognises.

It changed everything in about ten minutes, and I am slightly annoyed at myself for waiting so long.

what the thing actually does

A logic analyser samples a handful of digital lines, fast, and shows you the voltage on each one over time as a row of highs and lows. That is the whole idea. It does not measure analogue shapes the way a scope does, it just asks "is this line a 1 or a 0 right now" thousands or millions of times a second and draws the answer. For a digital bus, that is exactly what you want, because a digital bus is nothing but ones and zeroes arranged in an agreed order.

The cheap ones built around the FX2 chip pretend to be a particular branded analyser, and the open-source sigrok project, with its PulseView front end, drives them happily on Linux. I clipped the two probes onto SDA and SCL, grounded the analyser to the board, set a sample rate comfortably above the 100kHz bus speed, and hit capture.

the decoders are the real magic

Raw highs and lows are progress, but staring at a wall of square waves and counting clock edges by hand is its own kind of misery. The part that turned the lights on was the protocol decoder. PulseView ships with one for I2C: you tell it which channel is the clock and which is the data, and it overlays the meaning on top of the waveform. Start condition, address byte, the read/write bit, ACK or NAK, each data byte, the stop.

A close-up of a circuit board

Suddenly the bus was not a mystery, it was a transcript. And the transcript said something I had been completely wrong about. The address byte going out was correct. The device was ACKing it. So the device was there and listening, which ruled out half my theories in one go. What followed was a write that the device also ACKed, then a read where the device sent back its data perfectly well.

The data was fine. The bus was fine. The sensor was answering exactly as the datasheet promised.

the bug was never where i was looking

The fault, it turned out, was entirely in my code. I was reading the right register and getting the right bytes, then assembling them in the wrong order and applying a scaling factor meant for a different variant of the chip. The bus had been telling me the truth the entire week. I just had no way to hear it, so I had assumed the silence was the bus's fault and gone digging in the wiring, which is the one place the problem absolutely was not.

That is the thing about a logic analyser that no amount of reading about one prepares you for. It does not just help you fix the bug, it tells you which side of the wire the bug is on. Before, every failure looked the same: nothing works. After, a failure has a location. Either the bytes are wrong on the wire, in which case it is hardware or protocol, or the bytes are right on the wire, in which case put the multimeter down and go read your own software. That single fork in the road is worth the tenner on its own.

a few things i learned the hard way

A handful of notes for anyone about to clip one on for the first time:

  • Share a ground. The analyser and the board under test must agree on what zero volts means, or every reading is fiction.
  • Sample comfortably above the bus speed. A rule of thumb is at least four times the clock, more if you can spare the buffer, so the edges land cleanly between samples.
  • Mind the logic level. Plenty of cheap analysers are happiest at 3.3V or 5V and will not thank you for more. Check before you clip onto anything unusual.
  • Trigger on the start condition if your tool allows it, so you capture the transaction and not three seconds of idle bus.

I had quietly filed logic analysers under "proper test gear, not for me", the way you assume an oscilloscope is a serious purchase for serious people. They are not. For digital work this little board does ninety percent of what I actually need, and the software is free. The real cost was the week I spent guessing before I bought one. Buy the cheap tool. Stop debugging blind. The bus was never lying to me, I just had nothing to listen with.