ESP-WROOM-32 (ESP-32S) part


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/

Can not connect to pins on already existing part

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 :slight_smile: ), 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.



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.

Can not connect to pins on already existing part

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.



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.

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.

ESP-WROOM-32 [ESP-32S] Module_fixed.fzpz (20.4 KB)



Thanks for spelling it out for me. :grinning:

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.