ESP32-C3 sometimes won't execute code

[Alex Rossouw]

Every so often the board won't execute its code, and needs a manual reset just to reconnect the usb back onto my pc (win 10). I'm using platformio with the Arduino framework.

I have been using ESP's for a year and a half, I love them, however this C3 mini is a real pain sometimes.

Any ideas what exactly causes this? Bad code? Dodgy updates in one of my libs?

Any ideas will be much appreciated.

[ESP_Sprite]

Hard to say. What specific hardware (devboard, module, ..) is this? Any more hints on when this happens: after power-up, after a reset, after programming, ...? Is there any chance you can keep an USB-to-serial running on the UART Tx pin of the C3 to capture the boot message when this happens?

[Alex Rossouw]

The thing is the serial monitor prints nothing, no boot load, no core dump nor crash report. Sometimes there is a "waiting for download" msg printing tho.

What I do is I take my code apart, upload bit by bit and see what causes this behaviour. It's a pain, but it's the best fix I have so far.

I'm using a DFRotbot Beetle with an C3 mini chip. No debug pins are broken out unfortunately, so I don't know how to connect that to my pc and run a VSCode debugger or GDB or whatever is used for this.

[lbernstone]

This board looks like it does not have a UART->USB adapter; it is using the native USB connection. This means it does not have any way to show you the boot log (the USB cannot be active until the bootloader is started). I personally don't think these sorts of boards are appropriate for development (although they are great for production where you don't generally need to see the boot log, and will be programming them once).
You can see the serial log once the firmware starts. Make sure to enable "USB CDC on boot" from the tools menu. This will typically give you some indication at least if the device is in a boot loop or some basic activity.
If you have a standalone ftdi or cp2102 adapter around, that Firebeetle board does have the UART tx/rx pins exposed, so it would be pretty simple to wire up if you just have the occasional need to see the boot log. Since you can get an Espressif made board that has UART for $8 at amazon, I'd suggest buying one of those as a primary solution.

[ESP_Sprite]

This board looks like it does not have a UART->USB adapter; it is using the native USB connection. This means it does not have any way to show you the boot log (the USB cannot be active until the bootloader is started).

It's actually a bit more nuanced like that. Your assertion would be 100% correct on the ESP32-S2, which only has USB-OTG which is entirely software-driven and won't function in the bootloader. The ESP32-C3 (as well as the S3 and most newer ESP32 types) have an USB-serial-JTAG device, which implements the communications in hardware; the bootloader is perfectly capable of outputting data over that (and also actually does that). The issue there is that the USB-JTAG-serial device gets reset when the chip is reset, and enumerating the device takes most OSses a second or so, meaning you'll miss the initial bootup chatter. If the ESP32-C3 ends up in a boot loop or something else that keeps occurring when the chip is in bootloader code, you will still be able to see that over USB.

I also kinda disagree with your assertion that USB-only is not usable for development, at least for chips with the USB-serial-JTAG peripheral: every single ESP32-C3 and -S3 board I've developed lacks an USB-to-serial chip and I've been perfectly happy with that. I agree that you can run into issues like this, but they're fairly rare (in my experience at least) and having TxD and RxD as testpoints on the board is enough to debug these events.

[mikemoy]

I also kinda disagree with your assertion that USB-only is not usable for development, at least for chips with the USB-serial-JTAG peripheral: every single ESP32-C3 and -S3 board I've developed lacks an USB-to-serial chip and I've been perfectly happy with that. I agree that you can run into issues like this, but they're fairly rare (in my experience at least) and having TxD and RxD as testpoints on the board is enough to debug these events

Since you know what your doing it would be nice to see a clear cut step by step article with no link hopping around documentation to get debugging working in VSC. I have tried several times with no success. I would have thought using a ESP32-S3-DevkitC would have been baked into the debugger setup.

[ESP_Sprite]

mikemoy: I can't personally help you there, as I have never used VSCode in my life. Possibly start a new topic in the IDE subforum?

[Alex Rossouw]

Ok so after an hour of module testing, I found that 'one line of code' responsible for the bad behaviour I was seeing. I forgot that my battery library I wrote will set the board into hibernation mode (deep sleep without a timer wakeup) if battery voltage was low (no battery was even connected).

Yes...I feel most dumb. I guess that's on me, as I should've known that this was one of those situations that I needed to stop, and take a few days off because I had code blindness and I got into a nasty frustration loop.

HOWEVER, if I had a proper debugging tool, then that would be most helpful in situations like this, esp when I have 20+ libraries that I wrote. I wish a nice debugging tutorial would emerge for these new boards for VSCode with platformIO.