ESP32S3 corrupted flash?

Hey folks, so I have purchased some ESP32S3 dev boards from AXpress…. Normally C3’s which I ahev never had issues with, but of the 5 of these boards, two have suddenly start restarting with the following error

ESP-ROM:esp32s3-20210327
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x2b (SPI_FAST_FLASH_BOOT)
Saved PC:0x40043ac8
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce2820,len:0xfb0
load:0x3c8700ff,len:0xaf440
Invalid image block, can't boot.
ets_main.c 329

Now I tried succesfully flashing new boatloader, along with erasing flash first of course, and then I installed a sketch example of IDE and sadly, there is no difference!

(esptool-env) C:>esptool --port COM21 --baud 460800 write_flash -z 0x1000 firmware.bin
Warning: Deprecated: Command 'write_flash' is deprecated. Use 'write-flash' instead.
esptool v5.2.0
Connected to ESP32-S3 on COM21:
Chip type:          ESP32-S3 (QFN56) (revision v0.2)
Features:           Wi-Fi, BT 5 (LE), Dual Core + LP Core, 240MHz, Embedded Flash 4MB (XMC), Embedded PSRAM 2MB (AP_3v3)
Crystal frequency:  40MHz
USB mode:           USB-Serial/JTAG
MAC:                a0:f2:62:ec:63:4c

Stub flasher running.
Changing baud rate to 460800...
Changed.

Configuring flash size...
Flash will be erased from 0x00001000 to 0x001adfff...
Wrote 1753904 bytes (1148251 compressed) at 0x00001000 in 10.4 seconds (1348.5 kbit/s).
Hash of data verified.

Hard resetting via RTS pin...

Have I purchased faulty boards? I had successfully flashed them a few times without issue…. so they were ok, just not any more!

Serial comms were working well along with BLE and other functions (built in nanopixel etc).

One more thing, could this be settings within IDE?

Thanks

That last one looks normal I think. Did you press the reset button?

Have you connected anything to the ESP32S3 pins or are you getting this problem on a bare bones module ?

It constantly resets, same program runs on another just fine.

@srnet one of them yes, an i2c device that’s all. Soldered on atm as I was at a stage where all was looking good so wanted to try it in enclosure…

**just to add, it has programmed a few times in this config no problem!

Sorry, there are two issues with your reply.
First, what 'program' (we call them sketches) only test with the built in sample blink sketch. Bad code can cause your behaviour.
Second, in your post 1 I see normal operation. All successfull uploads end with that line.
Try the blink sketch, and when you see the line

Hard resetting via RTS pin...

press the reset button and see if the board blinks.

What else is connected to the board? Can you post an annotated schematic showing how it was wired. Also show your power source(s).

Writing at 0x00010000 [==============================] 100.0% 47/47 bytes...
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (618.2 kbit/s).
Hash of data verified.
Compressed 300640 bytes to 163713...

Writing at 0x00010000 [                              ]   0.0% 0/163713 bytes...

Writing at 0x0001bd7a [==>                           ]  10.0% 16384/163713 bytes...

Writing at 0x00028986 [=====>                        ]  20.0% 32768/163713 bytes...

Writing at 0x0002e26d [========>                     ]  30.0% 49152/163713 bytes...

Writing at 0x0003400b [===========>                  ]  40.0% 65536/163713 bytes...

Writing at 0x00039822 [==============>               ]  50.0% 81920/163713 bytes...

Writing at 0x0003f231 [=================>            ]  60.0% 98304/163713 bytes...

Writing at 0x00044ad9 [====================>         ]  70.1% 114688/163713 bytes...

Writing at 0x0004d671 [=======================>      ]  80.1% 131072/163713 bytes...

Writing at 0x000535f0 [==========================>   ]  90.1% 147456/163713 bytes...

Writing at 0x00059660 [==============================] 100.0% 163713/163713 bytes...
Wrote 300640 bytes (163713 compressed) at 0x00010000 in 1.7 seconds (1446.1 kbit/s).
Hash of data verified.

Hard resetting via RTS pin...

Now, when I press the reset, I get constant sound of connecting and disconnecting. BTW it did this on my work and home computer, with numerous different sketches written, and now including blink. I guess if the unit is constantly resetting with the message displayed with “
Invalid image block, can't boot.”, no sketch can run!

I even tried esptool to erase and rewrite bootrom again and this appeared to be successful.

Like I said, this has happened to two units out of 5, so I will continue with the other 3 and see if any of them give up in a similar way!

Never had this issue with C3’s, in fact the code that caused the issues was a C3 port, with some modifications… 50% memory used, 10 program memory!

Did you remember to change the board type? Not that I've ever forgotten to do that (cough!)...

This is basically it, barring charge IC, regulator, neopixel, which the latter I will remove anyway as I want very low quiescent current.

Reason for the resistor on the switch was simply because I had issues in deep sleep with pullups, so I went with an easier option!

Oh I forgot RGB LED on pins 10,11,12 with series resistors.

Sorry missed this, yeah, won’t program at all if I leave it on esp device or c3, so that is not the case here

I can only assume my devices are either a bad batch or something else has caused the issue.

I will see how I get on with the other boards… They are behaving for now!

You have wrong offset, afaik bootloader should go to 0x0 on ESP32-S3

0x0000: Bootloader
0x8000: Partition Table
0x10000: Application Binary

Oh thank you! Will try when I get home :-)

I recently found interesting tool, but only quickly tested it.
You could have a look how the "working" boards are set up and maybe even clone the flash (not personally tried).

So you have three ESPs that work, and two that don't, and all are from the same batch, or at least from the same order? I would suggest that you ask an AI if there are any known problems like yours with S3 clones that involve the flash memory. There is a known problem with ESP8266 clones that is a failure to wake from deep sleep, and that has been determined to be caused by the 8-pin serial flash chip, which can be solved by adding a pullup resistor. You appear to have a different problem, but the S3 also has one of those chips (probably under the cover), so there could be a similar issue. Anyway, it won't hurt to ask an AI if anyone else has experienced the same problem.

Thanks Sherman, but couple of points. They have sustained a number of programming sessions without issue just the latest, which to be fair, do involve playing with deep sleep but I have since cleared the memory!
Secondly, these are barebones, they are the ESP IC without a can, or external memory. The only support IC’s are the regulator and battery charger, along with a neopixel.

I put a post on Espressif but it doesn’t seem to have been authorised yet

AI has been pretty useless in this case sadly…

It’s a strange one…

Ok. Well I tried on Google, and got this response:

https://share.google/aimode/AlucntOtFxw4sEFZ8

The link is only good for 7 days. Maybe there's something in there that would be helpful.

Did you try powering from an external 3.3V regulator or power supply?

I went on line and found this:

On the esp32-S3 mini there may be restrictions on pins 8, 12, 13. On the ESP32-S3 (including most “Mini” / dev boards) there can be restrictions on GPIO 8, 12, and 13, but the exact limitations depend on how the board designer wired things. Here is the practical breakdown based on the ESP32-S3 silicon + common dev board usage.
ESP32-S3 GPIO 8, 12, 13 — Practical Restrictions
GPIO 8 Typical status: usable but often “busy” but requently used for: SPI flash / PSRAM signals (on some modules) and LCD / RGB data lines (on boards with displays).

Implications: May already be connected internally * do NOT repurpose unless you confirm
If tied to flash/PSRAM → hands off
If free on your board → OK for general I/O

Simple rule of thumb: If your board has external flash/PSRAM → avoid GPIO 8

GPIO 12, This is the important one, it is a is a boot strapping pin
It is sampled at reset to determine boot configuration which that means:
External pull-ups / pull-downs matter
Driving it wrong at boot can:
Prevent boot
Put chip in wrong mode

Common behavior: Often has internal pull-down/up requirements but can be used after boot.

Be careful;
Do NOT force high/low during reset
Avoid strong external drivers at power-up

Safe usage:
Input with weak pull
Output after boot (carefully)

GPIO 13 is generally safe, but check board usage, it is not a strapping pin

Caution: On some boards used for:
SPI (FSPI/HSPI)
JTAG
LCD/data lines

It is typically safe for:
Digital I/O
PWM
Interrupts

in conclusion:
GPIO Type Risk Level Notes
8 Peripheral MED-HIGH Often tied to flash/LCD
12 STRAPPING HIGH Boot-sensitive pin
13 General GPIO LOW Usually safe

Before using ANY ESP32-S3 pin: Look up your exact board schematic