Best way to troubleshoot unintended net connections

[zthart]

Hi all,

I’m running in to an issue with a prototype design with a short that I can’t quite uncover. I made an initial version of this board and had it sent off to be fabbed a few months ago. Before having it made I made sure to re-fill all my copper pours and ran the DRC a few times just to suss out any stupid mistakes, and the DRC report came back only with a few intentionally unconnected pads, and a handful of overlapping courtyard issues for components that were a few mils too close (all the pads for these footprints still had plenty of clearance), all basically non-issues for my needs.

The boards came back and passed my incredibly non-scientific visual inspection, but weren’t behaving once assembled. I narrowed down the issues to my power regulation circuit (ERC on the schematic passes). The quick and dirty TL;DR is that I’m regulating +12v from an off-board supply down to +5V that’s used in one portion of my design, and that same +5V down to +3.3V for another.

I eventually realized that, even on an unassembled board, the 3.3V net had a short to the ground plane somewhere. Now, I’ve made a handful of changes to the design in my project since I had this version manufactured, but I have the gerbers that I’d sent to the fab and pretty carefully checked the 3.3V net and Ground plane in the gerber viewer and can’t find any connections between the two nets. The current version of the design in Pcbnew has no DRC issues, and highlighting the +3.3V net gives me a pretty decent indication that there’s not a short between the two (in the current version of the design, at the very least). That said, I struggle to think that the pcb fab would have a consistent manufacturing error across every board I ordered, and I’ve validated that my design is within the manufacturing limitations of the fab service I used. I’d more readily believe I’ve messed up than every one of my boards being manufactured faultily.

I have noticed, though, that DRC doesn’t even seem to care about intersections of pads/traces/copper fills of non-connected nets - you can set this up pretty trivially by placing a component somewhere in a copper zone of a net un-connected to the component, filling it, then rotating the part around one of it’s pads such that a pad ends up intersecting with a filled portion of a copper zone. From here, run DRC and opt not to refill copper zones. In my testing, DRC doesn’t complain at all that there’s a non-ground pad intersecting a copper pour on the ground net. This seems somewhat understandable though since I was just prompted with the info that my zones were out of date, but I could still see showing an error here being useful.

So all this to arrive at the title, basically: Is there a good/reliable way beyond ERC in Eeschema and DRC in Pcbnew to check either kicad file for unintentional net connections/shorts? I’m running KiCad ver 5.1.9, but am happy to upgrade to any stable v5 release.

I want to make sure that I don’t send another round of prototypes off and throw away another $100 because of user error. Any advice or tips/tricks that y’all can provide would be greatly appreciated. Thanks!

[iabarry]

You should refill the zones as the last step before DRC.

The fill operation occurs as a singular event. When you move or rotate or whatever, the fill is NOT automagically redone and you have a problem.

[davidsrsb]

5.1.9 is old and many bugs have been fixed since, including some that allowed pad to zone shorts. You can take a back up and then should be able to update to 5.1.12 painlessly.

[paulvdh]

The combination of ERC and DRC is almost everything that is in KiCad and what KiCad can do.

A relatively common user error is making an unintentional short in the schematic, and these are sometimes hard to spot. For example a decoupling cap with wire drawn though it that shorts it (and thus the power supply)

In KiCad-nightly V6.0.0-rc1 both the ERC and DRC have been expanded a lot. I’m … curious what happens if you open a copy of your project in KiCad V6.0.0-rc1 and then run ERC and DRC. (Make sure you do not corrupt the original project)

You’ve written down a lengthy description, but in the end it does not add up to much and you don’t know what caused the short. Can you share this project? I’m curious to see where the short is, what it’s cause is and how it could be prevented in the future.

[zthart]

@iabarry

The fill operation occurs as a singular event. When you move or rotate or whatever, the fill is NOT automagically redone and you have a problem.

I was aware of this, I just used the elect-not-to-refill-zones example to show that, in my current version of KiCad, DRC was not preventing (or even calling out) pad-to-zone shorts. Frankly, I’m still not even sure that’s the cause of my woes. I’m just trying to find a reliable way to identify these problems in the future, since DRC didn’t appear to be cutting it.

That said:

@davidsrsb

5.1.9 is old and many bugs have been fixed since, including some that allowed pad to zone shorts. You can take a back up and then should be able to update to 5.1.12 painlessly.

@paulvdh

In KiCad-nightly V6.0.0-rc1 both the ERC and DRC have been expanded a lot.

If updating is the solution, or at least a good place to start, I’ll definitely take a stab and report back.

@paulvdh

You’ve written down a lengthy description, but in the end it does not add up to much and you don’t know what caused the short. Can you share this project? I’m curious to see where the short is, what it’s cause is and how it could be prevented in the future.

The trouble is that, considering I can’t find the short in pcbnew today, I’m not entirely sure it exists in my current iteration of the project. I’m happy to share the gerbers for the version of the board that has the short, but at that point you lose all the net info. You’d have to open the gerbers and the current project side by side and infer what’s what .

Let me update my KiCad install and see if the DRC spits anything new back at me - if I find the short I’ll definitely post back, otherwise I’ll post some project files for someone more keen-eyed than me to look over.

[retiredfeline]

An additional check I do is to use the Higklight Net function to go through every net on the board and satisfy myself that it connects the nodes it should and none that it shouldn’t. It’s tedious, but given the time and expense it takes to receive a board from the fab, it’s worthwhile effort for me.

[paulvdh]

Gerber files can be back-imported into KiCad. All the netlist info is encoded implicitly in the layout of the copper layers, and I have some experience with this:

Reverse engineering KiCad project from Gerber files

2021-09-06Txx:xx Work in Progress. Incomplete! 2021-09-06T15:15 It’s fairly complete now. Time for something completely different. Some help with proofreading and finding missing or unclear parts is appreciated. The goal of this reverse-engineering tutorial is to re-create a complete KiCad project from partial information. I assume the only information available is a schematic in some readable, (but not EDA form, such as a .pdf or a .png picture, and a set of gerber files. In short, the step…

The procedure is far from perfect and the amount of work depends a lot of the complexity of the project. Converting all the copper tracks is easy and quick, but all the footprint info is also lost and must be fixed manually before the “net info” is valid.

[zthart]

@paulvdh

The procedure is far from perfect and the amount of work depends a lot of the complexity of the project. Converting all the copper tracks is easy and quick, but all the footprint info is also lost and must be fixed manually before the “net info” is valid.

Looked over that writeup - definitely comprehensive, really nice work. You’re right that getting the copper layers back is mostly a breeze, everything after though might be a little time consuming haha. Luckily I think I’ve avoided needing to try it out this time.

I’m happy to report back though that I’ve found the short - a via on the +3.3v net is placed very nicely in a ground plane :

If I reproduce this error by manually changing the net of a via placed in a copper pour and then connecting that via to a pad I do get several DRC errors on v5.1.12. On v5.1.9, I can’t quite get into this state in the same way, but I can produce the same DRC error by starting to route a trace from a pad and placing a via in a copper pour mid-trace. It seems as though I’m not as infallible as I had hoped as far as always running DRC before plotting gerbers.

One strange behavior I did notice, common to both versions, is that vias placed in the middle of copper pours that are manually moved to a different net before running DRC (again, without refilling zones) are not pointed out as errors during DRC, and when the DRC dialog is closed, the vias are automatically changed to be the appropriate net for the zone they were placed in. I don’t have any strong opinions on this being good or bad UX, but it certainly isn’t what I’d expect.

I will say that even in v5.1.12 it looks like you can still replicate my contrived example previously of ignoring the “zones are out of date” dialog and getting DRC to happily report back no issues.

Obviously it’s totally “on me” for ignoring the popup about zones being out of date, but I’d still argue that this example should show something in the DRC. For every other DRC error, it’s up to the user to clear/igmore things that may be inconsequential to them - If someone really is fine with what’s going on in my first screenshot here I would think the software should still leave a marker pointing out the intersection, leaving it up to the user to clear. I didn’t try any of this out in the v6 rc since I couldn’t find a windows installer for the tagged build, and I didn’t want to set up the toolchain to build it locally.

I’m glad to have found my short, though, and I appreciate the advice in this thread. User error strikes again - I should probably highlight my nets more often and spend more time with “Show filled areas in zones” enabled. Probably would’ve caught this one before it made it to the fab.

[paulvdh]

You can probably save your boards by drilling out that via or removing a piece of that track. If needed, add a wire to where that track is supposed to go to.

The best remedy against such user errors is to work with a checklist.
Before I generate the final gerbers I always do an ERC validation, “Update PCB form Schematic”, refill zones and a final DRC.