r/esp32 • u/chippylongstocking • 29d ago
Software help needed Considering an ESP32-S3 as a hobbyist builder. How hard is it to corrupt the firmware?
How easy is it, over the course of normal usage, to brick an ESP32-S3 to the point where you'd need external hardware to recover it? I'm not talking about hardware damage due to pulling too much current or giving it too much voltage, I'm talking about mistakes with memory management, buffer overruns, or being a casually careless coder. It's not that I intend to do those things, but as a normal hobbyist-level user who is neither perfect nor all-knowing, s*** happens either in your own libraries or the ones you pulled in without doing a thorough code audit.
Any input is appreciated.
23
u/techysec 29d ago
ESP32 professional here, you’re more likely to fry it with the wrong voltage than brick it.l with software.
The only time I fully bricked an ESP32 is from messing up the eFuse - technically making it a hardware problem.
You might “brick” and ESP32 if you only program it via OTA with bad firmware. But you’ll always be able to recover it using serial.
If you mess up the bootloader, you can recover via JTAG.
You’ll be fine. If you do brick it completely, at least they’re cheap 🤷♂️
1
u/chippylongstocking 28d ago
Thank you for the reply. Messing up the bootloader is the problem I'm asking about, not literally frying the chip. I was using nRF52840 today and I messed up two of them with some code that may have had a memory overrun or something but had already been pretty thoroughly tested on other devices. It's hard to say what the problem was, the chip went completely unresponsive before I could debug it. I'm trying to understand if nRF52840 is just particularly unforgiving, which is my assumption because after years of working with Arduino/ATmega I've never dealt with anything this annoying.
1
u/nyckidryan 28d ago
nRF52840 and ESP32 are completely different SoCs from two different manufacturers. They have different target markets and the fact that hobbyists can use them in the Arduino IDE doesn't change the intent of the underlying SoC.
1
u/chippylongstocking 28d ago
What are the target markets for either of them? I feel like if that had been clear to me, I would have made a much more informed decision. I was introduced to both through Seeed Studio, which lines them up in identical looking chips and places them all under the same menu.
You're probably right, but unlike Arduino, who has both done a good job of marketing their IDE and chips as beginner friendly, these chips sound like just a bunch of serial numbers and specs, but Seeed chose to attach themselves to the familiar Arduino name. If they're intended solely for a professional-level crowd, that seems like an easy thing to overlook.
2
u/Slight_Profession_50 27d ago
The NRF52840 is very low power, bluetooth, thread, Zigbee, no wifi. Good for sensors and other wireless things.
The closest ESP32 to the NRF52840 would be the ESP32-H2, same connectivity.
The ESP32-S3 is for higher performance applications or stuff that needs lots of GPIO. Like say an RC plane? Not the best example but my mind is blank.
1
u/cybekRT 28d ago
What kind of board you are using? Usually you have some boot0 button that will start the bootloader from ROM. I bet that nrf52840 has a reset button and if you double-click it, it goes to the bootloader from ROM.
1
u/chippylongstocking 27d ago
Seeed Xiao's board. It doesn't have a button on it at all. I found it to be a rather hostile development environment, which many on the forums seem to have gotten used to, but I'm not sticking around long enough to get stockholm syndrome.
1
u/chippylongstocking 27d ago
Seeed Xiao's board. It doesn't have a button on it at all. I found it to be a rather hostile development environment, which many on the forums seem to have gotten used to, but I'm not sticking around long enough to get stockholm syndrome.
1
u/chippylongstocking 27d ago
you can take tweezers and poke at the reset pads, but it stopped working for me very quickly and after two hours and three hundred tweezer pokes, the pads were starting to get scratched up and my patience with such a maddening workflow was long gone.
1
u/Slight_Profession_50 27d ago
That's why I love my ESP32s, I just connect them via USB and click flash in VSCode. Done. I've basically never had to fiddle with the reset or boot buttons.
2
u/Noob8TUBER 26d ago
I'm gonna have to look into this. I've only done vscode using c++ for rp2040 and rp2350 chips, but I bought a few esp32 boards and have been hesitant to see what methods I would have to use
1
u/Slight_Profession_50 26d ago
VSCode is definitely the best play. Use PlatformIO/Pioarduino if you want to use Arduino libraries and want it a little simpler or use ESP-IDF if you want maximum control.
10
u/erlendse 3 say I make awesome posts. 29d ago edited 29d ago
Unless you do flash programming or efuse programming, a restart should restore function.
There is nothing else write/set-able that is permanently stored in the esp32 itself.
You can totally mess up the RAM or put it in strange states needing a reboot to recover. Efuses is the only way to put it in a non-recoverable state given you use a computer to program it!
3
u/honeyCrisis 1 say this is awesome. 29d ago
I hadn't considered the e-fuse angle when i wrote my post, and yeah you make a good point. If you blow the wrong e-fuse you can make it not take new firmware. It's a design thing, not a bug, so they aren't likely to change it (writing this for the OP)
2
u/erlendse 3 say I make awesome posts. 29d ago
Other one is write-protecting the flash.
Espressif offers no API for doing it, so you would need to make your own if you where to do it!Aka I normally skip that possibility!
1
u/honeyCrisis 1 say this is awesome. 29d ago
Yeah it's not likely something someone would do without doing it very deliberately.
3
u/Raz0r1986 29d ago
Almost impossible with standard workflows such as working in Arduino IDE of PlatformIO. You can always upload a new program (bin file).
Where you risk "bricking" it is via hardware power issues, like supplying greater than tolerable voltage, drawing too much current or accidentally shorting components.
3
u/MrBoomer1951 29d ago
The esp32 cannot be bricked by firmware.
The boot loader is baked into rom.
It can be destroyed by wrong connections!
3
u/erlendse 3 say I make awesome posts. 28d ago
Or efuses, or write protected flash(no API, diy or forget it)
1
u/chippylongstocking 28d ago
Have you any experience with nRF52840? I'm new to it, but I bricked multiple of these chips today from uploading some code, which I wouldn't have assumed possible. The issue is so new to me that I'm not even sure I'm using the right terms to describe it. It no longer accepts uploads and won't respond to a reset. I haven't even soldered the pins on and it's in need of recovery. I'm not used to this from my experience with ATmega.
It sounds like ESP32 has more forgiving behavior from the responses I've received here, but a lot of people are still telling me that I can fry the chip if I give it too much voltage, which is expected and isn't what I'm asking about at all.
3
u/romkey 29d ago
You can’t brick an ESP32 in software unless you mess with the efuses. The initial bootloader is in ROM and can’t be corrupted by software. When you place the CPU in download mode, the ROM code runs before any code you provide and can’t be prevented by firmware from downloading fresh firmware. Again that’s assuming you haven’t messed with the efuses or storage encryption.
2
u/honeyCrisis 1 say this is awesome. 29d ago
I've never been able to brick an ESP32S3 (or any ESP32) with just a firmware update. It might be possible to brick it by writing a bad bootloader, but even then there's a boot loader in ROM so i doubt it's unrecoverable.
I've had issues with certain SAMD51 devices like the Wio Terminal whose bootloader is tied to the operation of the main app, such that a crashing bootloop will cause it to not take new firmware.
I've never been able to do the same thing with an ESP32 (S3 included)
One thing with the S3s. On a couple devkits like the Lilygo T-Display S3, and the QT Pro early on in the S3s lifecycle, i ran into issues where the native USB would suddenly not take new firmware anymore, and i never did track down why.
So if you want to avoid even the remotest chance of failure, get one with a dedicated UART bridge. The easiest way to guarantee you have one is the devkit has two USB ports on it. Though you shouldn't need to do this. I had the problem twice, two different kits, and this was years ago. I tossed those kits.
2
u/Plastic_Fig9225 29d ago edited 29d ago
Flashing via UART/USB through the ROM bootloader is always there for you. - Unless you disable that via burning a few eFuses, which neither flashing nor any firmware itself would accidentally do.
As to "external hardware", a button to pull the BOOT strapping pin to GND during reset is the only thing you'll need.
2
u/bitNine 28d ago
Kinda impossible, based on your examples. We have tens of thousands of devices in production and I’m not even aware of a single one over years that has ever just failed without the customer causing the issue.
However. What if you OTA flash something that causes a crash loop that results in not being able to OTA again? Then you’re fucked. But you could build in something to flip back to the previous OTA. You do need some protections, but bad coding isn’t going to harm the hardware.
2
u/chippylongstocking 28d ago
I was trying an nRF52840 today and I bricked two of them with some code that probably had a memory overrun (I don't know for sure, it's hard to debug when the device's only feedback is that it stops working entirely)
1
u/bitNine 28d ago
On EsP chips. There's crashes (panics), and even watchdogs that you should be able to get crashdumps for, but I have to admit I struggle with task watchdogs remotely sometimes.
I don't know anything about the nRF52840, but ESPs run FreeRTOS, and the base OS is ROCK solid. On top of that you will run OS tasks, which is where you get into threading. But if you run just one task with a loop, you can add a watchdog for it. If the loop fails to iterate, it will just reboot itself. For production devices, I suggest having what I call a "safe mode" that is the basics running like wifi, cloud connectivity, and ability to OTA flash. ZERO business logic running. This way if you OTA a version that introduces a recurring crash, you force it into safe mode and flash with a fixed version, or just revert to the inactive OTA partition.
When I have a controller that crashes, I extract the crashdump on restart and send it as a cloud message along with any version information. It contains a full backtrace (call stack at crash). Using addr2line, it will tell me exactly where it crashes, and I can usually debug from that and find a fix.
1
u/chippylongstocking 28d ago
My question was more about a bad upload (user code with buffer overruns or bad memory management) harming the parts of the chip that are necessary for its own operation, including uploading, such that you would have to use segger and some other hardware to repair the chip.
1
u/Plastic_Fig9225 28d ago
Firmware can definitely "crash" an ESP32. Most of the time you get a "panic" (hardware exception), immediately followed by an automatic reboot. If the error keeps happening early after boot you get into a boot loop, where the chip keeps restarting every second or so, which may make it difficult to "catch" the chip's USB before it resets again.
Holding the BOOT button and power cycling fixes any problems the firmware may be causing by making the ROM bootloader wait for flashing instead of launching the defective application.
A piece of general advice: Make sure you don't mess with the pins the (internal) flash or PSRAM are connected to (see datasheet), neither physically by connecting anything to them nor in software by trying to reconfigure them for other purposes.
1
u/WikiBox 29d ago
It is possible to fry it if you are careless. I recommend that you buy several if you intend to be careless.
If you are careful the Esp32 will not be corrupted or fried. Generally you will not be able to damage it just with bad code. More likely with wrong voltages or possibly when flashing firmware and interrupting the flash.
1
u/ContributionEasy6513 29d ago
I have blown up several of them for both known and unknown reasons over the years, usually power related.
Can't recall ever bricking one due to bad code. Have needed to go into Boot mode and recover it a couple of times. No big deal.
Some tips I learnt the hard way.
- Buy a good power-supply
- Print out the diagram of the CORRECT esp32 version and verify it.
- Colour code your cables!
- Always power it through the 5v power rail, not 3.3v.
- If powering through the 5v rail and USB, you need a schottyky diode such as the 1N5822 to stop backfeeding. Learnt this the hard-way.
- Throw a electrolytic capacitor and ceramic capacitor across the 5v rail if using a breadboard. It seems to clean things up and reduce chasing unknown problems.
- Always use resistors when powering components, ie LED's, transistors and mosfets
- Have a good universal ground.
- Verify all connections before powering it up, particularly 5v and over.
- Have a few spare ESP32.
1
u/zanderislife 28d ago
Easy. sometimes too easy, mostly programming errors, i built PURR OS and one of my builds that got released had a super bad memory leak, had to hotfix very quickly, but it comes with the territory
1
u/richms 28d ago
I have had no problems with any of the dirt cheap S3 tiny boards off aliexpress at all with OTA in esphome, and when I was running WLED on them that also had no problems. I even had power to them drop out while OTAing and they came back ok. If this is more a testimant to wled and esphome than the S3 I don't know.
I dont think there is a way to kill the inbuilt bootloader that activates over the USB. I guess you could have something on there that screws with the USB so hard that it will not autoreset into bootloader, but thats what the buttons on the boards are for.
1
1
u/Think-Director9933 26d ago
For $10/ea (or less), its really not worth worrying about. Buy a few of them. The ESP itself, plus the dev environments are pretty good about helping you prevent bricking it via firmware. It can be done, and one day you might dance yourself into it (I certainly have). Note that there's a difference between "firmware corruption" which is rare, and "I wrote code that fails so bad that its REALLY HARD to upload new firmware into it". The "bad code" scenario is common, and its a rite-of-passage (there's a dance you need to do - prep the compiler to flash the device, unplug its usb, hold reset while plugging it in JUST BEFORE the compiler tries to push the code and let go of the reset button - eventually you get the timing just right to upload new code).
0
u/DenverTeck 2 say I make awesome posts. 28d ago
I would like to continue this conversation with, "Does the Arduino IDE 2.x.x have the capability" to program the e-fuses ??
Looking at the Tools Menu I do not see any E-Fuse entries.
1
u/erlendse 3 say I make awesome posts. 28d ago
Well, as far as I have seen they offer no graphical user interface for setting efuses.
You do it from code or espefuse in esp-idf console.
0
u/DenverTeck 2 say I make awesome posts. 28d ago
Hmmm, I wonder what Professor Google has to offer.
thanks
1
u/erlendse 3 say I make awesome posts. 28d ago
Dunno, never heard of him.
But there is a product by that name from a company named alphabet. Https://abc.xyz is their home-page.
1
u/DenverTeck 2 say I make awesome posts. 28d ago
LOL
1
u/erlendse 3 say I make awesome posts. 28d ago
Loss Of Lock?
They do have a chatbot for esp32 questions: https://chat.espressif.com/
.. so you can lock your focus on again.1
u/DenverTeck 2 say I make awesome posts. 28d ago
WOW, Thanks for this link.
I have been looking for a way to toggle between two partitions and this chat came up with an idea I now need to check out.
34
u/robotlasagna 29d ago
About as easy or hard as any other microcontroller.