Bricked ESP32-S3-Wrover? WT32SC01+ Development board

[theidealist]

Hello, I've been using micropython on and off as a hobbyist for a few years and have had a great time with it.

However, I recently purchased a WT32SC01+ development board and have now maybe bricked two of them when using micropython.

For both of them, the process went like this:

1. Confirm health and proper operation with firmware shipped from the factory
2. Upload micropython. The one today I used the following command, after building cleanly from source (the first device I used a recently-released binary and had the same result): /home/patrick/.espressif/python_env/idf5.1_py3.8_env/bin/python ../../../esp-idf/components/esptool_py/esptool/esptool.py -p /dev/ttyACM0 -b 460800 --before default_reset --after no_reset --chip esp32s3 write_flash --flash_mode dio --flash_size 8MB --flash_freq 80m 0x0 build-ESP32_GENERIC_S3/bootloader/bootloader.bin 0x8000 build-ESP32_GENERIC_S3/partition_table/partition-table.bin 0x10000 build-ESP32_GENERIC_S3/micropython.bin
3. Confirm micropython operation and control. I do this by connecting to the REPL with picocom and making sure I can import things, turn on and control the screen, etc.
4. Want to make changes to micropython, but I can't make any more changes.

If I try to interactively create files using the REPL, I get:

Terminal ready
The filesystem appears to be corrupted. If you had important data there, you
may want to make a flash snapshot to try to recover it. Otherwise, perform
factory reprogramming of MicroPython firmware (completely erase flash, followed
by firmware programming).

Traceback (most recent call last):
  File "_boot.py", line 11, in <module>
  File "inisetup.py", line 38, in setup
  File "inisetup.py", line 15, in check_bootsec
  File "inisetup.py", line 34, in fs_corrupted
KeyboardInterrupt: 
MicroPython v1.24.0-preview.278.g5e692d046.dirty on 2024-09-29; Generic ESP32S3 module with ESP32S3
Type "help()" for more information.
>>> import os
>>> os.listdir('')
[]
>>> with open('boot.py', 'w') as f:
...     f.write('Booting with boot.py...\n')
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 19] ENODEV

If I try to erase_flash, I get:

$ esptool.py -p /dev/ttyACM0 erase_flash
esptool.py v4.7.0
Serial port /dev/ttyACM0
Connecting......................................

A fatal error occurred: Failed to connect to Espressif device: No serial data received.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html

If I try to re-flash, I get:

A fatal error occurred: Failed to connect to ESP32-S3: No serial data received.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html

Following the docs, it would seem this development board maybe doesn't have hardware support for firmware reprogramming? But why did it work the first time so easily? Also, it says it can't connect to the serial port, but clearly it can because I can interact with it just fine via picocom and miniterm?

Any ideas on how I can recover these devices?

[davefes]

Had a look at the schematic and I don't see the usual transistor-pair used to control the boot lines (EN and IO0) for firmware upload.

Why do they supply a specific bootloader program?

[theidealist]

Had a look at the schematic and I don't see the usual transistor-pair used to control the boot lines (EN and IO0) for firmware upload.

Thanks so much for taking a look at the schematic. That is beyond my level at this stage!

Why do they supply a specific bootloader program?

I totally missed this?! Do you know how I can get my hands on that, and if it is too late if I've already overwritten the factory firmware? I did grab a copy of it prior to overwriting it, but now I'm not even sure how to write anything to it. My google search didn't turn up anything very good on this front. Did you find a specific bootloader program somewhere?

Thanks again!

[davefes]

https://www.seeedstudio.com/WT32-3-5-Inch-Display-p-5542.html?srsltid=AfmBOoowh-vqxxpMFNHaTb5hcqKZhWLAJmsCp0NolQS0M2PGaAxmdHvH

In Documentations

[theidealist]

Ah, the flash download tool? That went to a 404 for me, but it also went through some SSL certificate issues, so maybe something is up with the link.

Anyway, with your direction, and some more googling, I figured out that this is indeed as you suggested, a hardware issue.

1. Fortunately, I had already mistakenly bought one of these, which seems to be exactly what I needed. Plug this thing into the debug header and then you can use this as a programmer like normal.
2. I think you could skip the above route, based on this discussion, and just connect pin 6 to pin 7 with the little connector cable that comes as part of the kit I got. The only question in my mind is which end is pin 1 and which end is pin 7. I'm not proceeding down this route any further due to the good fortune I had in the above.

I'm still oncfused [sic] as to how the first firmware upload works on these boards, but I've also come to peace with the fact that this universe has many questions to which I will never know the answer...

[glenn20]

If you erase the first few blocks of the vfs filesystem, micropython will rebuild a new littlefs filesystem on the next boot, without erasing the micropython firmware. You should also use the same arguments to erase the flash that you did to flash the original firmware, eg:

esptool.py -p /dev/ttyACM0 -b 460800 --chip esp32s3 --flash_mode dio --flash_freq 80m erase_region 0x200000 0x4000

If that succeeds and all goes well, micropython will create the new filesystem on the next boot.

(You may also be able to use https://github.com/glenn20/mp-image-tool-esp32 that can help with investigating the partition table and rebuilding filesystems, etc.)

That won't explain why the filesystem appears to be corrupted in the first place, but it might help you recover and debug the issue.

[glenn20]

Oh - and it wont help if there is a deeper hardware issue at play - but it does seem that the micropython firmware is starting up - but failing to access the fs.

[theidealist]

Thanks for the recommendation. I tried this, but, yeah, same errors as before. It seems like something else and closer to the hardware is going on here. I can't seem to get it back into the right mode to accept anything with esptool.py...

[theidealist]

Thanks again for the help! This was indeed the answer once I got the HW issues sorted out. Many, many thanks!

[DavesCodeMusings]

Seems like you got it sorted, but I wanted to add one more suggestion that may be useful in the future. The --no-stub option for esptool. I had a device that refused to flash, giving similar "fatal errors" like you described. By adding --no-stub to the esptool command, I was able to write a new MicroPython image and save the device from being bricked. It did complain that erase is not supported by the ROM bootloader, but write operations worked just fine. This was on an ESP32-C3.