When the decode is wrong

The failure mode worth naming

A protocol decoder is a pattern matcher. Give it two channels and tell it which is which, and it will find start conditions, group bits into bytes and report them — and it will do that whether or not the two channels are the ones you meant.

There is no error state for "these are the wrong wires". The output looks like output.

The tell is in the trace, not in the bytes

You cannot spot a swapped pair by looking at the decoded row, because the addresses it produces are in range and the acknowledgements are plausible. You spot it one row up.

A clock is a metronome. On a real bus SCL is an even run of pulses with regular spacing, and SDA changes only while SCL is low. So if the row you have called the clock has long stretches with no edges in them, or changes level at moments the other row is also changing, it is not a clock.

That check takes two seconds and it is the first thing to do when a decode looks odd. Swapping two channel numbers in the decoder settings is far cheaper than re-clipping anything.

The three things that produce a wrong decode

The wrong channels. Covered above. The most expensive of the three, because it is the only one that produces confident, wrong output.

Too few samples per bit. The arithmetic chapter predicts this before you capture. Below about four samples a bit the decoder is not reading your traffic; it is finding patterns in an undersampled approximation of it, and reporting runs of 0x00 and 0xFF is what that usually looks like.

A gap in the stream. Dropped samples do not stop a capture. They leave a shorter transaction behind, and a shorter transaction is still a valid one as far as the decoder is concerned. A decode that works for the first half of a capture and disintegrates in the second is this, almost every time.

Notice that only the first is about wiring. The other two are settings you chose before pressing capture, which is the argument for reading the two chapters that cover them before the session rather than after it.

Failures that are honest

Not everything fails quietly, and it is worth knowing which ones announce themselves so you can be glad to see them.

• Both clips on the same wire gives the decoder two identical rows, no start condition, and an empty result. That is an unambiguous message.
• A completely dead bus gives two flat lines. Also unambiguous.
• SPI with the wrong clock phase shifts every byte by a bit, which reads as garbage rather than as data — obvious enough to chase.

The quiet ones are a swapped pair, an undersampled bus and a dropped sample. Those three are the reason to check the trace before trusting the row under it.

Working up the stack

When a stacked decoder — an I²C device decoder sitting on an I²C decoder — says something impossible, work upward rather than downward.

Only the top row came off the wire. Everything below it is software reading the row above using settings you supplied, so a nonsense register name at the bottom is nearly always a wrong channel or a wrong chip selection somewhere above it. Check the raw traces have edges, then the protocol decoder, then whatever is stacked on it. The silicon is the last suspect, not the first.