Hello,
I have been working on a PCB for a project that revolves around an ESP32-wroom. I have all of the components on the board and have most of the routing working fine according to the DRC.
My problem is that every single route to the ESP is found to be overlapped by the ESP itself. All of those routes are on the top of the PCB, as is the ESP.
Is there something about working with SMD chips that I am missing?
With your design loaded/open
Menubar: Routing>Autorouter/DRC Settings
There, you set the âKeepoutâ area. Thatâs the âGapâ distance between pads/traces.
Set it to a small value ( FYI : I set mine to 0.2mm
Note, if only issues are overlapping traces/pads and, youâre confident the design in other respects are O.K., then you can ignore the DRC errors.
Also, I would fix your traces so they are Perpendicular or at 45deg (for better Noise mitigation) and, with Better traces, youâll avoid them toucing PadsâŚ
If you post your file, someone will tweak it for you if needing helpâŚ
Thank you so much for all of the advice.
I think I feel confident in my file, but hesitate because I donât know what I donât know, ya know? A bit of help would an amazing boon!
hotrod-pins.fzz (64.2 KB)
Comments:
General suggestionsâŚ
Prepare your work/file by setting up these items
⢠View/working Grid
⢠DRC settings (anticipate the minimum distance needed to enable using Parts with tight spacing
⢠Set Via size and Trace Widths (can always change all or individually)
⢠Set the PCBâs Location (Top-Left corner) to 0,0, and set Units as preferred
⢠Lock the PCBâs position
⢠Set up Traces/etc for using Top or Bottom or Both (i.e., Single or Two-Sided PCB)
What I did:
⢠Reduced Keepout to very small value (only to help identify overlap issues)
⢠Tweaked and reduced width of Traces to be Straight/Perpendicular/Angled⌠to help Clean it up
⢠Slightly moved parts to help assess and tweak
Results:
⢠There seems to be an Issue with the ESP part and/or your hook-up.
I did Not try to fix it nor re-wire.
Nor can I assess the ESP part with the limited time available to me currently. Perhaps vanepp can look into thisâŚ
What is Needed:
⢠Determine if problem with ESP part
⢠Determine if Hook-up/Schematic is correct
As an Aid/Indicator, screenshots follow. Your file with my mentioned tweaks attachedâŚ
hotrod-pins.fzz (68.5 KB)
Thank you very much. I appreciate the tweaks made to the file, but value the provided guidance even more. I will take your suggestions and learn from them.
Do you happen to have a Monero address to which I could send a little tip?
No tipâs, but thanks. Appreciated.
Notice, I did not fully complete or try for good straight traces - I left enough for you to follow suit on remaining items. There are multiple ways/preferences of doing this stuff so, explore and tweak (all that aside from figuring out the ESP problemâŚ)
I see a number of problems, here. Gerbv ( a geber file viewer) of the gerber file from your fzz indicates you have some too close clearances and probably shorts on some of the pins:
The bottom trace on the left of the node mcu is close to shorting the next pad along. Iâd advise in pcb view View->Set grid size and reduce it to .01 in then bring the traces straight out from the mcu pads and make a bend later to give more clearance. The holes in the pads are a Fritzing artifact. The red dot indicates the connection point in the center of the pad, not a real hole. The gerber drill file indicates there are no holes in the node mcu part so that should be fine. When I looked at the node mcu part though there are translates on all the pads:
The gerber code doesnât (AFAIK) recognize translates. These seem to be within the view box, so will (and do) render but they may be in the incorrect place. Ungrouping all the pins will remove the translates. From the pcb of another nodemcu part that I downloaded a couple of years ago, the pads in your part look to be overly large as well.
You may want to switch to that part instead (as an aside, before making parts I always do a google search for âfritzing part ESP-WROOM-32â which in this case turns up this post where I fixed up the original part submitted a couple of years ago):
Peter
Thanks again, and thanks to you vanepp (Peter.)
I actually was working on replacing it with the part that you edited. I have taken consideration to straighten everything out as opera_night demonstrated, and had just finished doing that with the replacement ESP32 part when you posted.
Would you mind checking this updated one to see if there are problems with it? TBH, Iâm not sure what you mean by âtranslates on the pad.â
hotrod-pins-2.fzz (67.6 KB)
That looks fine, but drc is still unhappy. I think we decided in the original post that the spacing on the pads is too fine for drc.The gerbv output of the gerber files (which is what the board is made from) look fine:
The translate is in the blue circled part of xml editor on the right. What it does is apply a transform matrix to move the pad that has the black errors on the board on the left around somewhere. If the transform origins the pad outside the view box (which it can), the gerber code will not render it as it isnât in the viewbox. That isnât happening here, but it is likely the pad is offset from where it should be in the gerber file because the gerber code doesnât process transforms and will use the underlying coordinates (where the fritzing pcb view in fact applies the transforms and will look correct). Most of the time ungrouping the pads will apply the translates (sometimes it does not in which case you need to manually remove them which is a massive pain.) However looking again at @opera_night 's post, I realize the red marks are in fact drc output for the part in its original place. They will not move to the new position until drc is run again, so the translates may not be an issue in this case, although it is always safer to remove them because as noted, the Fritzing pcb view can look fine, but the gerber output is different (which is why you should always check the gerber output before ordering boards). That is likely a Fritzing bug as translates should be processed.
Some of my work using Fritzing requires setting DRC to 0.2mm Keepout. Iâve never had a problem with this small value. So, I was curious about the DRC errors on the ESP part and did some playing around andâŚ
When further reducing the Keepout to 0.1mm, errors still occurred on the ESP part.
Figure_1.
Does Fritzing have an issue with that small of a Keepout? No.
I set Two Pads next to one-another with gap smaller than Human Hair and No errors.
I added a resistor and connection close to a Pad, again, No errors.
Figure_2.
I loaded the File âhotrod-pin-2â from the Post above and it Errored as expected.
I Copied the ESP part and pasted into new sketch/pcb.
It did Not error.
I added a Resistor without connections.
It did Not error.
Figure_3 and Figure_4.
Added two SuperFine(8mil) connections from Resistor to two random Pads on ESP.
It errored. Further, errors occur on unused pads!
I did not explore the actual ESP Part file.
Aside from the above, I noticed in the Schematic, un-fully-connected terminals; perhaps not a problem for the design intent, just want to mention it⌠(the Blue Oval).
Good catch! I didnât check schematic or breadboard (my bad!). This is potentially a serious problem, as it may indicate database corruption caused by changing wires in different views. The usual solution to that is harsh, scrap the sketch and start again, or remove all the wires in all views (which amounts to close to the same thing, but leaves the components placed) and rewire, starting to completion in one view then clicking on the rats nest lines in the other 2 views and carefully moving the traces (so as not to make unexpected new connections which cause the database corruption) to recreate the sketch. Its been a long time (a year or more) since we had one of these but they are ugly and on my list to try and do something about when we get development going again, although Iâm not sure what the solution is. Iâll have a look at the sketch in all views again and see what I can see, but it sure looks like a corrupted sketch at first glance.
Edit:
I think he has dodged the bullet. As far as I can see it is only an unrouted rats nest line in schematic not db corruption. From breadboard and pcb, pin 13 B3 should go to ground and clicking on and rerouting the rats nest line in schematic completes routing and makes it go to ground. Fixing that however doesnât make drc any happier (as it shouldnât). Iâll poke some more.
edit2:
I think we are looking at database corruption. I deleted all traces in pcb and ran drc. It complains about 2 of the vias in clear space overlapping. Deleting the vias and dragging in new ones does the same thing. I think its time for a quick rewire from scratch âŚ
edit3:
Turns out Iâm at fault. I at some point fixed the translates in the posted part, but did not upload the fixed part. I just cleaned it up a bit more and did a delete minus (which deletes the part but keeps the traces) and jiggled all the traces to reconnect them (always a pain!) and now the new sketch with the new part passes drc fine.
hotrod-pins-3.fzz (69.3 KB)
Iâll finish the job by replacing the part in the original thread with the current one, so anyone further getting the part wonât have this problem.
Peter
Peter, thank you so much for your help with this! And again, thanks for the valuable knowledge.
Iâm pretty excited to have my first PCB fabricated!
Good luck, hopefully it will go well. Fritizng usually rocks despite its warts!
Peter
Good day again gentlemen.
May I ask for another review of my Fritzing please?
I was only able to find the AD5206 in SMD form, so it was necessary to rearrange things some. I also added a switch for bootloader mode.
I didnât use autoroute at all, did this entirely manually. I found it to be quite a pleasurable challenge. 
The DRC still gives me the overlap errors with the ESP, but everything else seems happy enough.
hotrod-pins-4.fzz (73.1 KB)
CommentsâŚ
I tweaked your file a bit - just enough to show (what I think) are better Traces.
Recommend:
⢠Increase trace widths to 16mil (I set One trace to 16mil - itâs obvious which). Generally, always prefer to have thicker traces on non-super fine layout and low current.
⢠Angled traces are best at 45deg, if possible
It still DRC errors on ESP. I did NOT do any other cleanup or fixing⌠The Tweaked file attached.
TWEAKED_hotrod-pins-4.fzz (73.6 KB)
Thank you very much.
I see now what youâve been saying about 45 degree angles. I misunderstood previously, thinking that was preferred when a 90 degree angle canât be done. Itâs a lot clearer now.
Appreciate it again.
I did much the same, but somewhat more agressively. First it is good to make DRC work because in this case it was trying to point out a problem that got lost in the clutter. The problem with DRC is you used the old part that has DRC problems, so I started with hotrod-pins-4.fzz and did a delete minus on the esp part which results in this:
DRC is reporting errors (marked 1) on the overlap of two copper traces. This isnât deadly it will work fine but can be fixed. The problem all the other errors were masking is marked be 2: there is a short between two pins of the connector because the bottom line trace covers the copper of both the first and second pins. DRC is correctly objecting to that. As well there are a bunch of redundant vias, Iâm guessing that is because you couldnât get a trace to connect to a trace. In Fritzing that wonât work, you need to connect a pin to a pin (easiest is to double click the rats nest line then move the resulting trace to the layer you want (top or bottom) change its size if needed then drag it to an appropriate route.
This image shows the correct. I deleted the wire and then connected one wire (outlined in red) between two of the vias, and the other wire (outlined in blue) between one common and one different via to complete the connection in a way that will pass DRC. In this image all the redundant vias (that I am about to remove) are circled in red and an alternate path that will reduce vias again is shown:
Then I went ahead and removed all except 1 redundant via (the one I left is anchoring a connection to the missing esp for now and will be removed later that via is circled in red here):
Now switch to schematic (because there is a Fritzing bug that I havenât yet found a fix for where parts dragged in to pcb or breadboard enter schematic at random rotations) and load the fixed ESP32 part (which will pass DRC correctly):
Here I dragged the end of the 3 wires ending on pin 2 so that they are all separate (because we need to drag each of them on to pin 2 to reconnect them which is impossible if they are all overlayed on pin 2). Before taking this snip, I grabbed the red dot on the end of the wire on each pin, moved it back from the pin, then dragged it forward again until the pin turned from red (not connected) to green connected). All the pins except pin 2 are already done here.
Now I did the same to one connection on pin 2:
You need to do the other two pin 2 connections to cause schematic routing to be complete. Once schematic is complete switch back to pcb and do the same thing to the ESP chip, click on it and drag it til the pins all line up with the traces, then drag each trace back a bit then forward til it connects and the pin goes from red to green to indicate a connection. The end result of that is this sketch which passes DRC and has a lot fewer vias (which is a good thing!):
you will see I was too lazy to adjust all the traces to 45 degrees as should be done ( and as @opera_night did), so you should probably do that, along with verifying all the traces look right because I made a number of changes.
hotrod-pins-5.fzz (70.5 KB)
Peter
Well thanks again Peter. I am most certainly learning a lot from this endeavor!
I wonder if I got a cached download or something - I thought I had downloaded the new part in your previous thread on this chip.
I take satisfaction in the fact that in the time since I posted that file, I found many of the issues you highlighted and fixed; I guess this is finally absorbing in. I did indeed connect directly to and from vias - that seemed like a good shortcut. I will avoid doing so in the future. Iâm gathering that this program just has its quirks and ways of doing things that only experience will bring about. I think I am starting to get the hang of it.
Just for the record, the assistance and education you guys are giving me will be paid forward in kind. This particular project is work related, but Iâm doing it because I love making things. I volunteer at various schools in my community teaching children how to program and do rudimentary electronics (usually revolving around the Raspberry Pi.) Everything I learn in my professional and hobby time is eventually passed on to those who come next. So thanks to you @vanepp and @opera_night for contributing to that!
So I have a question about the handling of parts with Fritzing. I downloaded the fzz file attached to your post, opened it and immediately ran DRC. It gave me the same warnings of overlapping with that ESP32.
Do I just have the broken one loaded in my parts bin, and it is being referenced here instead of the correct one? Or is it expected to still see those errors at this point - I may not have entirely followed the logic of your earlier post regarding fixing the ESP32 part.
Unfortunately til we can get somebody working on documentation that is how everybody learns: asking in here. That is how I learned pretty much everything I know about Fritizng and those I learned from are no longer posting in the Forums so I get to pay their kindness forward.
That sounds good, and yes Fritzing has quirks and bugs (hopefully with development going again the bugs will go down and maybe the quirks too 
). You may want to change to 0.9.4 pre release which is available in the Releases section of Fritzing-parts on github. It has bug fixes for an unloadable part corrupting the database and Parts Editor not deleting the parts files (my number 1 and number 2 annoyances which drove me to fix them) as well as a number of other fixes from the years since development stopped. It will be put out as a release, but it is taking longer that they expected because the tools and web site are in worse shape than expected.
This is odd. You shouldnât have a broken one in your parts bin, as then the new sketch shouldnât load. My new part is in the temp parts bin and I believe there should be a load conflict and the load should fail. That said, just to make sure I (or 0.9.4 pre release which I am running) didnât screw something up, I just downloaded the hotrod-pins-5.fzz file I loaded as hotrod-pins-6.fzz, started Fritzing 0.9.4 pre release (which has bug fixes) and ran DRC and it runs fine:
as you see my new part along with your connector is appearing in the temp parts bin and DRC is running clean. I then switched to another machine that is running 0.9.3b (to make sure this isnât a 0.9.4 bug of some kind) but it runs the same there. The part in the temp directory is contained in the .fzz file, and should cause a load conflict if there is already a part with that moduleId loaded in Fritzing. The only thing I can suggest is you try clearing the user directories (noting this will destroy any other sketches you have, so keep a backup copy) and see if that helps. It may be subtle corruption in the database files. Here are the instructions to clear the user data base files:
There are two user directories (with your parts and the parts database) which donât get touched during an install (to not affect your sketchs during upgrades). On Windows they are in
c:\users\username\AppData\Fritzing\roaming\Fritzing (which is a hidden directory so you need to enable hidden directories in explorer) and
c:\Users\username\My Documents\Fritzing (where username is your windows id)
If you donât have any parts or sketches you want to keep you can just delete those two directories and Fritzing will receate them, or you can move them aside by renaming them if you wan to keep something in them.
linux
~/Documents/Fritzing/parts
~/.config/Fritzing
Mac
/Users/username/Documents/Fritzing/parts
~/.config/Fritzing
Peter
