ALeggeUp's USB DFU and HID "Blinky" Build Log

I went off on a little tangent with this project, I started off creating the symbol for the ESP32 and spent some time fiddling with what information I wanted in my symbol, I based it on a combination of a few that I’ve seen that I liked.

Then when I placed it in the schematic I got distracted by the page layout and wondered how one goes about putting a logo on their schematic which lead me down a path of bitmap2component → s-expression polygons → svg → Inkscape → svg2shenzhen → childhood inspiration…

In the end, I spent way to much time on it, but it was a lot of fun. This is what I came up with.

Now to get back to actually working on figuring out what components I need and want for this board.

If you return to this symbol, you may want to add some more indication of special pin considerations. I can see you have IO0/BOOT0 labelled but there are also a few other considerations around “strapping” at boot. On the original ESP32 IO10 needed special care and from the ESP32 S2 datasheet it looks like IO45 and IO46 have this function. There may be other titbits to add? Anyway, I didn’t want you to get derailed, just wanted to say I find it helpful to warn myself about special pin considerations in the part symbol.

1 Like

That’s a great point, I was struggling with how much to include with all the pin functions and not having something like RTC_GPIO14, GPIO14, TOUCH14, ADC2_CH3, FSPIWP, FSPIDQS for one pin.

The strapping pins (IO0, IO45 and IO46) have a whole page of info with a table of combinations, I’m not sure what to show in the symbol to indicate that, but I think it’s a great idea. Do you have any examples on what would be a good indicator for that?

Which is a good plan, seeing how many pin functions can be reassigned IIRC.

I don’t have a good strategy other than to make it something that will jog your memory when you see it. Perhaps have an ASCII scheme of symbols that mean something to you, such as an asterisk for boot-related pins, maybe another symbol for the main peripherals you’ll likely use.

Looking at the module datasheet, maybe put something in to remind you not to leave EN floating? Maybe the ^ symbol? Also, I don’t know if you have a footprint yet for this module but you may want to number the GND pin(s)/pad(s) so the symbol matches up with the footprint.

There are also these notes in the pinout, which may be worth representing somehow:

  1. IO18 on the module is pulled up to VDD33 through a 10 kΩ resistor. For details, please refer to Figure 5 and Figure 6.
  2. IO26 is used by the embedded PSRAM on the ESP32-S2-MINI-1-N4R2 and ESP32-S2-MINI-1U-N4R2 modules, and cannot be used for other purposes.
1 Like

Thanks for the input @smerrett79, I really like the idea of having that info there right in the symbol. I fiddled around with it a bit and came up with this:

The GND pins and pads are all numbered, they all match up with the symbol, all of the GND pins exist in the same location in the symbol so I can connect them all together easily

Here’s the footprint that I created from the datasheet

1 Like

Great, that looks more useful already. Please ignore if this input is taking things too far but I’ll offer it in case it’s welcome:

KiCad has some conventions when it comes to parts that the project would include in its “built-in” libraries. First one that comes to mind is using background fill for the part box. S3.3 Symbol outline and fill requirements - Library Conventions | KiCad EDA I think the fill colour disappears (to white) if you export a black and white version of the schematic in pdf, so it shouldn’t impact readability if printed on paper, for example.

The second one is that they place power pins top and bottom, and put port/GPIO pins in memory order, rather than where they leave the package physically. S4.2 Pins should be grouped by function - Library Conventions | KiCad EDA I find this latter aspect frustrating when assigning pin roles in my schematic capture so I often ignore it when making my own parts. But just letting you know.

As I said, please ignore those considerations but I thought I’d highlight them while we’re talking about symbol creation.

I would also point out that I think the note about IO26 only applies to the N4R2 version (has the PSRAM and the N4 doesn’t?), and I didn’t want you to feel limited on that pin if you were using the N4 version (although the small price difference and perhaps better availability may make you want to plan not to use IO26 so you don’t have to worry about which version you can get your hands on).

I note something that is interesting to me about the ESP32 S2 MINI 1 schematics, which is that they have a filter on their 3V3 power input but apparently not on their VDDA analogue power input.

. It’s similar on the original WROOM modules too, so I wonder why they do that. I would have thought you want the analogue supply to be more filtered than the main supply. But I’m sure they know what they’re doing!

1 Like

Sweet, thanks!

Of course! Any and all input is very welcome!

Oh right, that rings a bell, I forgot about the KiCad conventions… I’ll read through those again.

I knew about the power at the top and ground at the bottom but didn’t do it since I had that extra info there, but now that I’ve made it wider that might work again.

The GPIO pins in memory order is a new one to me, I have heard about grouping them by function but since most of them can be reassigned it seemed like something I wouldn’t know until I got further down the line.

Oh, good catch, I’ll try to make the note less “hands-offy”, but you’re right I’ll probably not need it, I’ve got many more GPIO pins than I’ll probably need for a while.

I see what you mean, but won’t pretend to understand if that will ever cause me an issue… My “needs” for this one are pretty simple and all digital so I think I can ignore that for now?