[[STM32 USB Breakout 2.canvas|STM32 USB Breakout 2]] ## Walkthrough Notes ### Broken Reference to Symbol Library ![[Pasted image 20241210081006.png]] In this case, I have cloned KiCAD project files from GitHub, but our libraries aren't identical. This missing component symbol is also not connected to the rest of the schematic, since it doesn't have pins. Deleting and replacing this component with one of the same name won't necessarily fix the problem. When I pass that update over to the Board Layout, I'll have to replace the old footprint as well. So really, I have a functional footprint. What I don't have is a functional symbol. Rather than deleting, it makes more sense to just go into the properties and update the symbol's library reference. ![[Pasted image 20241210081322.png]] `Update Symbol From Library` is for when you have made changes to the library, and you want the symbol you changed at the library level to show in the schematic. In this case, we're coupled to the wrong (non-existent) symbol, so that won't help us. Instead, I need to `Change Symbol` and point it to one that actually exists. ![[Pasted image 20241210081541.png]] It wasn't that big of a change from `Device:Ferrite_Bead_Small` to `Device:FerriteBead`, but it does make a difference. Note that the footprint remains the same. We only changed the Library reference for the symbol within this Component. Maybe another useful way to think about this is that every Component contains a Symbol and a Footprint library reference, and you can switch either one out arbitrarily. ![[Pasted image 20241210081652.png]] It looks right now. Next is to pass the changes to the PCB and check for any new problems. Switching to the USB and updating from Schematic did not produce a new component that needed placement. The existing component was already placed and required no updates. So this is looking just fine. ![[Pasted image 20241210081921.png]] Note the stray ratsnest lines. This is a strong indicator something's up. See below: ### Running ERC on someone else's design I figure it makes sense to run ERC on someone else's design before you start fiddling with it. Who knows what kind of errors your machine will produce. Your rulesets might be different. Once you change something, you want to know if that change created an error, after all. ![[Pasted image 20241210084022.png]] ![[Pasted image 20241210082856.png]] Here I've got 38 Errors, 4 Warnings, and 1 Ignored Test (No SPICE model) Most of it seems to come from another Symbol mismatch. His STM32F pins on the right side are on the bottom, aligned with the left side. Mine are Top-Right, so none of those connections are being made correctly. I can fix this by simply shifting all the net labels and components upward so they're connecting to the right pins. PA1 goes to the LED as a reference point. You can clear all the visual clutter with `Delete All Markers` in the ERC without messing something up. Just re-run the ERC later to get them to show up again. ![[Pasted image 20241210083949.png]] That looks better. There are some similar issues going on with the power pins. His older version of this symbol has more power pins and their placements are just slightly different from mine. This requires cleanup too. Once that's taken care of, the number of errors is reduced to 2. Two instances of the `Error: Input Power pin not driven by any Output Power pins` for `VCC` and `3.3VA`. There are several flavors of Power Rail in this Schematic: - VBUS (from USB) - +5V (from USB) - VCC (after input filtering, voltage regulator input) - VO (voltage regulator output) - +3.3V (voltage regulator output) - +3.3VA (after further input filtering for analog use) VBUS and VO are recognized as a power output pins. The rest are all considered power input pins and expect to be powered directly by one of the two outputs. VCC and +3.3VA do not have a direct connection to a power output pin, they go through at least one component and are not attached to the same node, so they produce the error. The error can be dismissed, or you can attach `PWR_FLAG`'s to them, to recast them as power outputs. Now, back to the PCB to check the DRC ### Running DRC on someone else's design The extra ratsnest lines on the PCB are gone now since all the right connections are made. Taking the time to clear the errors on the ERC will simplify the DRC by a lot. There are 0 errors and 4 warning on the PCB now. There were dozens before. 2 Warning for edgecuts intersecting silkscreens on the USB terminal outline. 2 Footprint library mismatches ![[Pasted image 20241210091606.png]] What's happening here with U2 is the library reference is correct and points to an actual entry in the Footprint Library, but when KiCAD checks the footprint, the one in the project and the one in the library are not identical. This is when we run `Update Footprint from Library`. When I run that though, I get a new error from the DRC because there are new silkscreen components on the updated U2 footprint that intersect the solder mask. ![[Pasted image 20241210091952.png]] In this case, we already have a silkscreen dot to indicate where pin 1 goes. Though this does make the case that the footprint containing that dot is actually way smarter than having to place the dot manually on your board every time. I'm not sure why it was in the tutorial like that. Maybe that's just one of the improvement points from the last couple years. Either way, having a trace running directly through silkscreen like that isn't acceptable, so I'll have to adjust the footprint, reroute the trace, or both. **Note:** There's a notice on the Footprint Editor that says "*Editing U2 from board. Saving will update the board only*." I think that means I can edit just this instance of the footprint and it won't affect my library if I, say, delete that triangle. But now, if I run the DRC again, I get our original error, that it doesn't match the library's version of the footprint. **And we've come full circle.** In this case, let's allow the library mismatch and dismiss that error, along with the one for the voltage regulator. After ignoring the warning, one more update from schematic and one more DRC and we get a perfect result - no warning and no errors. Good to go. ![[Pasted image 20241210093049.png]]