Case study · Interconnect

Two boards, both correct, and five volts on a Raspberry Pi

A carrier and a plug-in power module. Sixty contacts. Every contact passes, and correctly so. Seat the module and its 5 V rail arrives on three signals that were never meant to see it — one of them a pin on the Raspberry Pi’s forty-pin header, where 3.3 V is the ceiling.

E-Sharp Accordion M1 carrier  ·  Mini-PSU Precision Module

This is a real finding from one of our own design reviews — caught by Probe Interconnect, the cross-board add-on to our PCB design-review tool. Here is what it saw.

Every automated check in a normal flow looks at one board at a time.

That sounds harmless. It is not. A board that is wrong only in relation to the board it mates with is invisible to all of them, and it passes with a clean sheet. There is nothing to find, because on that board there is nothing wrong.

Here is one of ours.

The assembly is our Accordion M1 test carrier with a plug-in Mini-PSU Precision Module. The carrier hosts a Raspberry Pi, which runs the instrument. The module drops into a sixty-contact connector on the carrier, straight in, no cable and no adaptor.

Both boards had been reviewed. Both were clean. Both were right.

On the module side of that connector, four contacts are all the same net: the module’s own 5 V rail, brought out to four positions the way a power pin usually is. That is ordinary and sensible.

On the carrier side, those same four positions are four different nets. One of them is the carrier’s 5 V rail, which is the intent. The other three are general-purpose I/O.

So seating the module joins its 5 V rail to three signal nets. Two of them run to an I/O expander that is supplied from 3.3 V. The third runs to the Raspberry Pi’s forty-pin header, and a Pi’s I/O is a 3.3 V part with no tolerance for five. A fourth contact does the same thing one rail down, putting the module’s 3.3 V onto another Pi line.

Why every contact passes

Contact by contact, nothing is in conflict. Take any one of those sixty positions and ask the ordinary question — is something driving against something else here? — and the answer is no, correctly. On the carrier side the net is an input with nothing driving it. On the module side it is a rail. No two outputs face each other. Nothing is shorted on either board. Every contact scores clean, and every one of those scores is right.

The hazard is not in any contact. It is in what the contacts join. Two nets that are each perfectly well-behaved become one node the moment the connector seats, and the node is a rail wired to a logic input. You cannot see that by looking at contacts, because it is not a property of a contact. It is a property of the pair.

The mating itself is not in doubt, which somehow makes it worse. Twenty-three ground contacts line up against twenty-three grounds, so the connector is unambiguously the right way round. This is not an orientation mistake or a mirrored footprint. It is two correct boards that disagree about what four positions on a shared connector are for, and nothing on either drawing says which of them is the authority.

For thirty-one of the sixty contacts there was not enough on file to compare at all — a pin function nobody had recorded on one side or the other. Thirty-one unknowns is not a clean result, and it should not be allowed to look like one. It is a list of things to go and find out.

How Interconnect found itProbe Interconnect treated the assembly as one product rather than two boards near each other, composed both pin maps through the mating, and asked for each contact what it joins rather than what it is. It returned twenty agreements, nine contradictions and thirty-one contacts it could not compare — and refused to let the unknowns score as clean.

Both boards passed everything they owned. The defect was never on either of them.

Cross-board analysis is provided by Interconnect, a separately licensed add-on to Probe. Single-board review does not include it, and could not have produced this finding.

The defect was never on either board

Interconnect treats a mated assembly as one product, composes both pin maps through the connector, and asks what each contact joins — the check no single-board review can run. It cites every contact to its source.