I have two SOT23 components next to each other, both are connected to the same ground pour with a via, but the left component gives a DRC “Error: Missing connection between items”.
It looks pretty connected to me. I’ve tried routing a trace directly to other ground pins but get the same error on this particular pin. I checked that I didn’t accidentally add the footprint twice. If I put the via somewhere else and rout it to the pad the DRC error is still there, it just points to the last segment of the trace that attaches to the pad centre. Making a ground pour on the front layer also doesn’t help.
Sorry for not posting the full layout, but the ground plane is well connected and contiguous to that pin and via, and if it wasn’t then the ground pin of the component on the right should throw up the same error.
I have a feeling that if I submit the gerber files, the final PCB would have a correct connection, but I’m missing some something Kicad.
Look at other places of GND-pins / the GND-pour. The DRC-arrow for not connected zones points not always to the best location.
You can also see at the bottom status-bar the text “Unrouted == 1” displayed which indicates that somewhere a connection is missing.
To be connected to a pad a track must start at the origin of the pad, not some random point within the copper area of the pad. You’re probably missing a tiny bit of track between the origin of the pad and the via.
Not really.
If a track starts from the center of a pad, then KiCad is sure to recognize it as connected, but there is some tolerance. Quite often KiCad also recognizes the connection when it’s off a bit. However, it is quite possible that KiCad does not recognize the connection in this case because of this reason and I do not tend to rely on this and normally always start a track from the center of a pad.
Also:
Via’s through pads are usually not done because it is an reliability issue. The via sucks up a part of the solder, and there may not be enough left on the pad for a reliable connection. This is not such a problem for hand soldering, but if you work with solder stencils, then the amount of solder is fixed and this becomes a real issue. If it can’t be avoided (for example on very densely populated PCB’s) then usually and extra step is made to fill the via’s with epoxy.
The DRC error shown does not have an arrow, I can only click on the list items to have them highlighted. The unrouted == 1 item is the highlighted GND via on the left of my screenshot. Everything Kicad is giving me indicates that the error is pad 2 of the footprint on the left, and that Kicad thinks it’s not connected to the ground plane, even though there is a via in the pad.
Kicad seems to be pretty permissive of uncentred tracks, as long as they intersect with the pad it counts it as a connection.
However, for the screenshot I shared I deliberately deleted the tracks and just put a via in the centre of the pad, and Kicad is still giving me an unconnected error. If I put a via near the pad I get no error for the via, Kicad knows it’s correctly connected to the ground plane, but as soon as I move it onto the pad or make a track from it to the pad, the error appears.
In the shared screenshot, there is no track, only the via, and the error is still there. Since Kicad auto starts the trace in the centre if your start routing from the pad, I know that uncentred traces aren’t the problem. I can add multiple traces, all to different connected ground pins or pads, and I will always get this error on this component pad 2 only.
The footprint itself is SOT-23 Handsolder, and the component will be hand soldered. I was originally putting the via just next to the pad and adding a short trace, but for the sake of clarity in the screenshot I just put a via in the middle of the pad to show that a via to a correctly configured ground plane is being flagged with an unconnected error. The error is only for this one pad 2 on this one component. The via to the right is connected to the same ground plane, and is on pad 2 of an identical component (they’re both Y2 SS8550 SOT-23 BJTs).
For further info, if I connect the pad directly to the adjacent correct pad, the error is still there:
It’s likely that KiCad normally recognizes that both the GND pads are connected to each other via the via’s and the zone area on the other side. I suspect however, that piece of the zone is a small isolated area and not connected to the rest of the GND net of the PCB. In such cases KiCad can not know what is the “most important” part, and it just shows the error in a somewhat random place.
OK, I found the issue, there had been another pad on a completely different component where I had missed a via to the ground plane. I’m still confused as to why the error checker chose this specific transistor pad to flag the error, as it was fully connected to ground plane and the ground plane itself is contiguous, but didn’t flag an error on the unrelated pad that actually was unconnected.
Many thanks for your help. Normally I avoid cluttering forums with my stupid problems, but I was really banging my head with this one.
KiCad sees two different “islands” that should be connected, but it can’t know where the connection should be. So it’ll highlight one mostly random item from each island (the error message is multiline and each line corresponds to one island). So if one item looks connected just fine, look at the other line.
Also of course look for ratsnest lines, which might be easier in general.
Thanks for your reply. In this case I think my error was that I rerouted a short data trace on the back side closer to my MCU, and consequently the ground pour had been pushed away from the GND pin on the MCU. However, Kicad didn’t show any yellow indicator arrow or ratsnest line to this pin because it was connected to the GND pad on an SMD cap, so Kicad seemed to regard it as “connected” somehow, whereas it treated the entire ground plane as “unconnected” and chose a random GND pad to assign the unconnected error to.
Unfortunately it meant I wasn’t able to clearly see what the error was. I’ll have to be more careful about pushing traces around in future. Sorry for using the forum as a rubber ducky debugger!
