For anyone who are interested in prototyping with the ESP32 modules, here is the part that I’ve made.
You can download the part from here: github .com/troelssiggaard/ESP32-fritzing-module/
1 Like
You have a few problems. Connector39 to 50 have layer=“unknown” in the fpz file which means the connections aren’t active in any of the views for those pins (they need to change to breadboard, schematic, pcb as appropriate). Your view box is also over large, but thats not a big issue, but in Inkscape edit->select all then file-> document properties->resize page to content will fix it. In schematic the connections are connecting to the center of the pin because you haven’t defined an appropriate terminal in the schematic svg (although they are specified in the fpz). I usually use a rectangle .01 by .01 centered on the end point of the pin as the terminal. PCB looks ok to me (but I don’t do much with pcbs either 
), you probably should add an outline drawing to the silkscreen layer though. As well the url listed above github .com/troelssiggaard/ESP32-fritzing-module/ has a space between the github and the .com which makes it not work on a cut and paste.
Peter
Here is a working version. It still needs a silkscreen for the pcb and may have other issues but I believe it is usable for making a pcb.
EDIT: The file uploaded here still had issues. I have fixed it completely and should work for everyone. The original had issues with in the fzp file as well as scaling issues that took some time to fix.
Here is a new part with the fzp file fixed so all the connections work and the scaling has been fixed so it produces the correct PCB footprint.
EDIT: See Vanepp’s version below.
1 Like
Unfortunately there was more wrong than just the scaling. Some of the pins in schematic were also wrong (likely due to the pins not being in sequence) and the grounds weren’t bussed. In the end I renumbered the pins as that was easier than trying to figure out the current scheme and cleaned up schematic and changed a couple of pins that don’'t match the current data sheet on the manufacturer’s site.
edit: replaced by a new part posted below.
Peter
What makes them “wrong”. They work and they are connected to the correct pins in other views. I feel this is what I was mentioning about your script. It is strict in trying to enforce the manual file creation method where the parts editor lets you link any pin to any other pin in any view you want. They do not need to the same names or numbers or anything else.
Also are you 100% sure the grounds are bussed on the little breakout board that holds the actual esp32 chip? I was not sure and so I left them unbussed enuring they all get connected to ground eternally so you can’t leave one unconnected thinking it was connected internally.
I was going to have a look at what you did in fritzing but you again uploaded a part that can not be loaded because you manually changed the files but you didn’t change the unique id that makes it different from the one I uploaded making them incompatible with each other. I will also not replace the one I have with yours because it would likely break the sketches I’ve designed around my part.
OK, I have created my version as a new part below which will load separate from the original. In the original schematic note that there is one too many grounds, and pins pin 15 to 19 are out of order, CMD is missing and IO20 on pin 32 is shown as NC instead according to the data sheet at.
https://www.espressif.com/sites/default/files/documentation/esp-wroom-32_datasheet_en.pdf
The pins in breadboard don’t match up with those in schematic (I didn’t check if pcb matched, it may have). That the grounds may not be internally bused is correct as I don’t have one.
edit (oct 2019): I just discovered that I had fixed but not updated this part. The old part fails drc due to translates in the copper1 layer. This new part removes those translates and passes drc correctly (at least so far). If you are using this part you may want to grab the new one.
ESP-WROOM-32 [ESP-32S] Module-fixed.fzpz (19.4 KB)
Peter
1 Like
Thanks for spelling it out for me. 
The extra ground in the schematic was labeled wrong as you say. You changed it from GND in schematic and RTS everywhere else to CMD everywhere which goes better with the SD2 and SD3 around it.
The pins being out of order I think are because this was based off of a breadboard friendly breakout board that someone had made and the pins matched the breakout board. Then someone made the module alone and just reused the schematic.
Good catch on there being no GPIO20 and actually being NC.
Whenever I am trying to figure out the connections for one of these modules I always go and find one of these cheat sheets so I can see all the different possible labels for each pin. I also use it while making connections instead of relying entirely on the labels.
Last thing is my part has nicer mouse overs then yours. When you mouse over any of my pins they just say what the label is. With yours it shows Fritzing pin number which is of zero use and only confuses things. Like if you mouse over IO12 on your board it says PIN14:IO12 and on my board it says IO12. This makes the chance of making a mistake that much greater. I think this may be because you assign them in the svg where as the editor assigns them in the fzp file? Not that it really matters just something I noticed while comparing them.
Not the svg its all in the fzp file. The difference is likely that the editor is setting both the description and the name field to the same thing and it then supresses one of them. Does it also manage to supress the internal label somehow (that is annoying but I don’t know of a way to get rid of it)? That is also a reason to have the pins in sequence since (due to a bug I expect) Fritzing will screw up the labels when the pins are not in sequence. It appears to assume the next number and labels it wrong then generally screws up the label on the next pin along before recovering.
Peter
@vanepp After using this ESP32 file, why I cannot autoroute connected wires. All connected wires are lost after autoroute.
Upload the .fzz file with the 7th button
What he was asking for is the sketch that you used the part in (thus the fzz file). The part is thought to be working, the problem is likely in your sketch. I don’t normally use autoroute and thus don’t test against it, but I don’t remember anything strange in the part that should affect autorouting.
Peter
OK for me autorouting works (as much as autorouting ever works). However it appears to not be able to route the traces to the wroom, I expect because the default trace size is too large. I tried setting the scale on the pcb down to .02 in but that doesn’t help. In general the autorouter does terrible pcb layouts and no one uses it. You are much better off to hand route the board. In this case you probably need to reduce the trace size in inspector to route the wroom although the default trace size does appear to work with the grid size set to .025 inch.
testwroom05.fzz (36.2 KB)
Peter
2 Likes
I believe the pin spacing of the ESP32 is too small for Fritzing in general. If you manually route a board and try running the DRC you will find it gives you 2 complaints about every connection you make to the ESP32 even with the smallest traces. You must be knowledgeable enough about trace spacing to route them by eye. I have had many boards made up for the ESP32 and they work but again that is based on my ability to get the spacing correct by eye and not relying on autorouting and DRC.
1 Like
Yeah, professionals don’t use auto route. AR was designed when boards had traces north south on the top layer, and east west on the bottom layer - maybe 70s/80s -, and it did a decent job. PCBs now have traces everywhere and it doesn’t work efficiently anymore. Not even $9K of Altium does a good job.
2 Likes
Thank @vanepp for enlightening me about the default trace size is too large. First, I think the program should give any warning messages or reduce trace size automatically.
It seems that frizting cannot handle small parts automatically.
No choice now. I have to do all routes by manual.