When I design my schematic or the PCB layout,
I find myself often clicking on that ERC or the DRC buttons to ensure my designs conform
to the rules. I find it pretty fun to click on that ladybug
icon 🐞 But some errors happen pretty repeatedly
as part of the designing process. So, in today's video I want to go through
three common ERC or Electrical Rules Check in the Schematic, as well as DRC or Design
Rules Check in the PCB Layout Editor. And end off with a discussion on how I use
it as the philosophy of TDD (Test-driven Development), in small steps with some aspiration to use
it with automation in the future. At the very beginning of making the
schematic, I typically need to connect the the various pins of different schematic symbols. Let's start with a common error that is a
conflict between pins. We will connect the BUSY pin of this E-Ink
module. In the schematic, when we run the ERC there
is one error. It shows a conflict between pin 1 (the BUSY
pin) of U6 (the E-Ink module) and pin 10 of J4 (the JTAG SWD connector). We can solve this error, by opening the symbol
editor to find out the type of pin. Pin 1 of U6 is an "output", whereas pin
10 of J4 is an "open collector". We can edit the pin to pin connection as part
of the options in ERC. By default, when an output pin connects to
an open collector pin, it is an error. Just for fun, let's change it to a warning
and run the ERC again. The ERC will correctly give a warning with
the same message. Can we change it to green and passing? Yes, the ERC has no errors at all. So we can use these options to configure for
individual projects, but I will change it back to the default options and run the ERC
again. It shows an error like before. Let's fix the error! Pin 1 of E-Ink should be connected to the
microcontroller's Pin 30 that is a bidirectional pin. In the ERC options, the bidirectional pin
connecting to an output pin should give no error. Let's run the ERC one last time. Awesome! There are no more errors! Now that some of the pins are connected, we
are left with the other pins. After solving the conflict between the pins,
the second most common error that I get is the unconnected pins. For this example, we will use the LoRa module
by HopeRF, but not all the pins are connected. Back in the schematic, U5 is the LoRa module
component designator. Let's run the ERC. And there are five errors of the same type,
pin not connected in U5. This type of error is easy to solve. All we need to do is place a "no connection"
symbol in each of the unconnected pins. Let's run the ERC again! There you see, all the errors are gone! The last most common type of ERC error that
I get is pin not driven. To understand this problem, let's start with
a very popular dev board, the Arduino UNO. Even if we don't connect the pins and use
the no connection symbol, while the 5V and GND are connected with their corresponding
power symbols, the ERC will not pass. Two errors say the same thing, "Pin connected
to other pins, but not driven by any pin". I don't know whether this is unique to KiCad
as a tool, but to solve it, we can use the power flag symbol, which is a special symbol
for telling ERC where the power comes from. We need one power flag for the 5V and another
one for the GND. Now when we run the ERC, there are no more
errors. Let's extend this example a little further
by adding a common temperature sensor DHT11 to the digital pin D4. The power symbols, 5V and GND are also
added, but this time no special power flags will be required because we have already added
them to the same net. When we run the ERC, there are no errors. But now, when we add an open solder jumper
to the Vcc and run the ERC, the error will appear again. This time it will be at the Vcc pin of the
sensor because of course, it cannot be powered because of the open solder jumper. To pass the ERC, we have to add a power flag
to this pin. After annotating everything, there are no
errors. Do read this informative KiCad forum thread
on this particular error. I found it helpful to understand what was
going wrong. While the ERC deals with our schematic design,
the DRC, or also known as Design Rules Check does something similar for our PCB layout. The first common type of DRC error is pad
too close. When we import all the footprints into the
PCB layout editor, it will typically display all the components as a rats nest. At this instant, when we run the DRC, it should
have no errors, but lots of unconnected items. After some crucial design decisions, we do
the component placement without laying a single track or filled zones. Now when we run the DRC, there is the same
number of unconnected items, but 19 errors! The error message is "Pad too close to pad",
and these pads seem to be from the same footprint. For example, Pad 1 and Pad 2 of `JP2`. I located these errors. They seemed to come from 3 types of footprints,
which are the micro USB, the TQFN and the open solder jumpers. This type of error was very baffling
to me. I used these footprints from the library. I did not create them. And I have not yet routed a single track! After some sleuthing, I finally solved it. Click the property of each of the footprints
affected, go to the tab called "Local clearance and Settings" and change the Pad clearance. By default, it is 0mm but check with the
manufacturer's capabilities. For example, I use PCBWay to manufacture PCBs. The minimum spacing here is 0.1mm but strongly
suggested to design spacing above 0.15mm. Back in KiCad, I put the pad clearance to
0.2mm for all the footprints affected because it's best not to push the manufacturer's capabilities. Now when I run the DRC, I should have the
same number of unconnected items, but no errors! PCBs are eventually a matter of tackling various
physical constraints especially when we are trying to pack components closer. As part of DRC, we can check for courtyard
or boundary overlaps. For example, it's useful to place mounting
holes on our PCBs using M2, M3 screws, nuts, or spacers. They do have boundaries beyond the holes. By default, in KiCad the DRC check does not
include courtyards. Go to Board Setup, Design Rules to check the
box called "Prohibit overlapping courtayrds". Now when we run the DRC, there will be an error
for the courtyard. Let's move this M3 screw footprint just a
little, refill the copper zone again to run the DRC. No errors! The last DRC error happens frequently towards
the end of my PCB layout. While I'm laying the long routes through the
filled zones, I get an unrelated message that I have unconnected items even after I just
routed the track! Let's look at this example, where I am left
with just one unconnected route as shown by this rat's nest line. When I run the DRC, it correctly says I have
one unconnected item. So let's route it. Something like this. And that should clear the last remaining unconnected
item, right? But when I run the DRC, yes I don't have any
errors. But there is still an unconnected item and
it's not the same as what I routed! So confusing! I finally figured out what happened. Let's zoom out to see the big picture. While routing the final track, I split the
top filled zone into 2 parts. One on the right, the other on the left. To fix this, we need to adjust the last track
so that the filled zones get connected. Let's try again! I run the DRC and no more unconnected items. Now that we have covered some of the most
common ERC/DRC errors, the question is how do we use them? I can't help but take some inspiration from
the software domain with Test-Driven Development philosophy. Firstly, I try to do these checks often. In the schematic, I run the ERC after I complete
each logical block. I don't try to add more schematic elements
without running the ERC so that I am not overwhelmed by the number of errors later. Secondly, I tie these ERC/DRC checks with
the Git version control. For example, in the PCB layout, whenever I
complete a group of related routes, I run the DRC, solve all the errors and git commit
the project immediately. And lastly, using ERC/DRC as part of continuous
integration automatically. Now, I admit I have not done it before, so
it remains as an aspiration. In the hardware world, this is not a norm
yet, but people are definitely trying! There are some repositories of such automation
utility as well as forum discussions on integrating DRC as part of continuous integration. I am definitely looking forward to an evolving
landscape with respect to integrating ERC/DRC in CI easily. I would love to know your common errors in
ERC and DRC. Now, the choice of tool, whether it's KiCad,
Altium, Eagle does not really matter. It's the concepts that are more important. So drop your comments below about your thoughts,
about how we can use them like TDD. And let's have a discussion on how we can
run these checks better. So thanks for watching and see you next time!
