ESP32-S3 Unresponsive After SD Logging

[TobyG99]

Hi, I'm looking for some help regarding an issue I'm having with an ESP32-S3-WROOM-1U module on a custom board. I'm using ESP-IDF. It seems like I have corrupted the flash/bricked the ESP, and I'm trying to understand why that happened so I don't do it again.

The exact module is the ESP32-S3-WROOM-1U N16R8: https://www.espressif.com/sites/default ... eet_en.pdf (Uses

For initial context, this is a control board with CAN, I2C and UART components. The SD is being used for updates and the pins are:
- MISO: GPIO13
- CLK: GPIO12
- MOSI: GPIO 11
- CS: GPIO10

During development, I'm using an FTDI programmer and UART0 (RXD0, TXD0) for programming, which has been working fine.

Initially, everything worked when running SD card operations, I was able to check the SD card for folders and install updates from a .bin file correctly. Recently, I modified my program to run SD card operations alongside other peripherals (e.g., CAN, I2C, UART) and log states to a file for testing (every minute). During this, I messed up a semaphore and it threw the ESP into a boot-loop, which I could initially monitor via my FTDI programmer.

After I fixed that issue, I attempted to reprogram with no serial response from the ESP. I then attempted to enter bootloader mode via GPIO0 and erase the flash using esptool, which wouldn't connect either. Following the data sheet, I ensured all strapping pins were in the correct state for bootloader mode which they were.

I then tested on an identical fresh custom board with the exact same method of programming and hardware, with the new SD log routine removed, and it worked fine. So I can be certain that it it due to the new SD logging routine.

In case it was the UART that caused the programming issues, I soldered a USB onto GPIO 19 and 20 (the S3s internal USB peripheral), and it wasn't even read as a port on my PC (the other identical board was). Adding to this, the module heats significantly when powered, which I assumed was due to the boot loop and constant initialisation attempts.

To summarise what I've tried:
- Attempted to force bootloader mode by grounding GPIO0 during reset, and checking other strapping pins
- Verified power supply stability and ensured it delivers 3.3V within acceptable tolerances
- Checked the board for visible damage, shorts, or soldering issues
- Attempted to use the USB interface incase of UART or FTDI issues
- Been unable to replicate the issue on my second board with the logging routine removed

I understand it may be difficult to understand why this occurred, but aside from removing the SD logging routine entirely (which I have done for now), I don't exactly know what to avoid to prevent this in the future. As far as I've read, corrupting the ESP32 through software is nearly impossible because of the ROM bootloader. However, I can't see another reason, unless this is coincidental and I shorted something on the board at the exact time I attempted to fix the program issue, which seems unlikely.

Could running SD card routines simultaneously with other peripherals have caused permanent hardware damage (e.g., through power spikes, GPIO conflicts, or SPI contention)?

Are there any additional recovery steps I can try to revive the ESP32-S3 module? I've resigned to swapping it out for now, but may be useful to know in the future.

What design precautions should I consider to avoid similar issues?

Any insights or suggestions would be greatly appreciated, and I can provide more details if needed.

Thanks in advance for any help.

[ESP_Sprite]

You could check what the ESP32 tells you on its serial port when it boots up, if any. The chip heating up while bootlooping is not behaviour I expect, however, and lowering GPIO0 while resetting the chip should get it out of that boot loop anyway. To be honest, sounds to me like you somehow killed the module.

[TobyG99]

Thanks for the reply. In terms of monitoring on power up, I can stick an analyzer on it and have a look if I'm getting anything at all. But I agree with you, it seems like the module itself has died.

Since then I've been testing with the second board and had no issue, so it does seem to be the SD card routine/boot loop error that caused the issue.. or simply a coincidence and happened at the same time as static/shorting.