The main thing I wanted to provide with this programmer was the SOT-223 footprint so a large capacity LDO can be added, hopefully preventing brown-outs, especially when powering multiple devices during development. In addition to containing an ESP DTR/RTS reset circuit, the 4 GPIOs on the CP2102N have been broken out. Also broken out are 6 grounds, 5v from the USB and an extra 3.3V pin.
I've been using the one successful module for a little while now. It handled programming the #ATTENTION: SuperCon AddOn beautifully and in fact is the fastest serial programmer I have, happily running a 2M baud. I'm not sure if this is the difference between the CP2102 and the CP2102N, but other devices with CP210* don't seem to go above 921600.
Features and Feature Creep
By design, I wanted to keep this as simple as possible but right away a couple things popped up.
Yup, that button is useful, sometimes I *reaally* want to be certain EN is being pulled down. One case is working with these ESP32 Camera modules that oh so helpfully put the reset button on the bottom side of the board, making it inaccessible when breadboarded.
This has also got me thinking a lot more about the ESP reset circuit, I've implemented it dozens of times now but don't really know what's going on. Also in the case of the camera module, the onboard reset circuit doesn't work. I believe this is because the flash LED is connected to GPIO0 (boot mode select) and the reset circuit isn't able to fully pull GPIO0 to ground.
From what I do understand, it's to ensure the BOOT/EN are toggled in the right order....? Or something. Feel free to chime in!
I want to try some tests with modifying that circuit to provide open-drain on IO0, ensuring those are pulled down regardless of other components being on that pin.
Sometimes toggling EN just isn't good enough. I've broken out the 4 available GPIOs from the CP2102 but I'm now considering using at least one for a specific purpose. For this build I used a plain 1117-3.3 regulator for sheer simplicity but since have come to really like the AP2112K. While it doesn't provide the 1A that the 1117 does (that is still somewhat ironically resulting in Brown Outs....) it does have an EN pin. I believe either GPIO2 or 3 will be suitable to keep this pin high without user intervention (default state) but some more digging in will be required.
I'm thinking the next version will be something between the current version and what will become V2, call it V1-feature-creep-test. Something that will allow me to test some of these ideas but still be flexible enough to work.
Since the last post there has been content for at least two updates. In fact, I'm so certain of this that I was shocked to see there was only one log post. And that that in it's self was so short I'll just go ahead and quote it in it's entirety right here.
Boards ordered, should have next week. Pretty sure I've got all the parts.
That is all.
Weeeellll turns out while I did have parts I didn't have enough. Of course with only 2 CP2102N's left on hand, I exercised zero extra caution, immediately frying one of them.
For my next trick I lifted pads of the USB connector on one of the other boards.
This left me with a single pristine board, and without hot air on hand, zero USB chips.
Frustrated I just ordered more. Except I ordered QFN20, instead of QFN24. Yyyyyyaaaaaaaay. I didn't want to put in another small order with a large one coming up, I thought this project might get shelved for a bit.
On to the good part.
I've been working on modding a pair of reflow ovens at a near by hardware oriented co-working space, Circuit Launch and needed some test boards. And with hot air available.... why not try to recover that one not yet shorted CP2102...
Not only did I manage to get it off, the reflow worked quite well despite the vintage paste I was using.
I didn't have any ESP boards with all the needed pins available on hand but did manage a quick serial port test.
And as you might have noticed from the picture above, I have to get creative with the... *ahem* "Are these 1206 cap?" I'm not even certain they're fully connected. But once I did manage a full ESP32 test several things where noticed. First, it worked! Very pleased with that. But it was really inconsistent. I was seeing a lot of long waits and frequent failures while flashing.
Putting properly fitting caps helped this situation but I do still see long waits.
The other thing that didn't work brings up one of the reasons I really like the CP2102N. These have a programmable Serial ID. This is really handy for keeping track of various devices that might not be in sight or tracking which firmware is currently flashed. Problem is, it wouldn't work!
If anyone could shed some inside into either the inconsistencies or why I cannot change that serial ID please leave a comment. So far I'm pleased with the project and plan to do a second iteration soon. Lack of indicator LEDs is bugging me and I might add a physical reset button.