The Capture File With No Label

In one line

Even a capture file with no names written on it explains itself. The number of channels, the idle level, and the relationships among the lines are enough to tell which bus it is.

Why this was needed

The files you receive in the field usually have no names. They say only ch0 and ch1, and the person who measured says only "it doesn't work here". If you ask which bus it is, the answer that comes back is "the wires coming out of the sensor". Sometimes there is no one to ask again. Then you have to ask the file.

This module ties the three earlier buses together. Knowing each one is a different skill from telling them apart without knowing what it is. And the latter is the one needed in the field.

How it works

You begin the sorting with the cheapest clues.

The number of channels. One line means asynchronous serial (UART). There is no clock, so you must find out the speed yourself. Two lines most likely means I2C — if one line is a regular clock and the other changes only during the low intervals of that clock, it is almost certain. Four lines means SPI. One is a select line that stays low throughout the transfer, and one is a clock that runs only inside it.

The idle level. Where the line sits when nothing is happening says a lot. UART and I2C rest high. So when you meet a one-line capture that rests low, you suspect the polarity was flipped. Either an inverting level shifter was put in between, or an RS-232 signal was measured mistaken for TTL. If you read the values as they are, you cannot find the start bit and the frames are picked out wrong, but if you read with every bit flipped, a sound sentence comes out.

The relationships among the lines. In a two-line capture, if one line makes a change during the other line's high interval, that is a START or STOP. In a four-line capture, if a line changes at each edge of another line, it is data. If there is a line that never changes during the whole transfer, that is information too — it means the slave never drove MISO. Either the select was wrong, the chip is not attached, or there is no power. A line with only the pull-up left always reads as 0xFF.

When you name a fault, write the evidence with it. Instead of "the baud rate doesn't match", write "the shortest pulse is 112 µs but the nominal bit time is 104.2 µs". The former cannot be checked by the next person and the latter can. And a report that cannot be checked becomes a rumor as time passes.

채널 1 · 유휴 낮음        -> UART, 극성 반전 의심
채널 2 · STOP 없음        -> I2C, SDA 가 붙들려 버스가 잠김
채널 4 · MISO 모서리 0개  -> SPI, 대상이 응답하지 않음

When choosing the numbers to use as evidence, it is better to include both a counted value and a measured value. A counted value is an integer, like the number of STARTs, the number of sample edges, or the number of leftover bits. If it is wrong, it is definitely wrong, so there is no dispute. A measured value is a continuous quantity, like a rise time, a bit time, or the length of a low interval. It varies a little with the threshold and the sample rate, so you must write those down as well for the next person to get the same value. If you write only one of the two, the report is half-done — with only counts, you do not know how much margin is left, and with only times, you do not know what happened how many times.

And keeping to the order of using the cheapest clues first actually saves time. The number of channels and the idle level come out from reading just the first few lines of the file. If the bus is settled there, you only need to decode by that bus's rules, and if it is not settled, it is not yet time to use a decoder. Starting with decoding and repeating "the result is strange" is the most common waste of time in this work.

Finally there remains writing down what you cannot do. This course's capture files are all synthesized waveforms. The edges were made with a first-order RC, and no noise, jitter, or reflection was put in. So "normal" as judged here does not mean it is normal on a real board. The decoder being right and the signal having margin are different claims, and the latter requires real-hardware measurement and a comparison with the datasheet's VIH, VIL, and timing values. If you do not write this boundary in the report, the reader ends up believing more than what was read.

What it looks like in the field

Often an incident report comes up with just the one line "I2C error". With that one line, no one can decide the next action. Who fixes it differs depending on whether the address is NACKed, the bus is locked up, or the rise is slow — the first is firmware, the second is the driver's recovery procedure, and the third is hardware. If you sort these three out from the waveform, one line of the report points to one person in charge.

Conversely, a report that only attaches a name without evidence is dangerous too. "It's because of noise" is almost always another way of saying "we don't know yet". To say it is noise, you must put forward the interval where the noise is visible and its size.

What you will do in the next lab

You decode four I2C captures and three SPI captures. They are a normal read transfer, an address with no response, a slave that holds the clock, a bus with a weak pull-up, modes 0 and 3, and a transfer with a late select line. In the last step you receive three captures with no names, sort out which bus each is, and attach a name and numeric evidence to the fault.