Did I brick my LilyGO T-Dongle-S3 (ESP32-S3)?

[digisaster]

I bought two LilyGO T-Dongle-S3 devices and flashed the first one with the v1.1.2 release. Because I had issues mounting the SD card and using a USB keyboard, I followed the step “Blowing eFuses to increase USB compatibility.” After that, everything seemed fine.

Then I took the second dongle and installed the latest firmware from the web browser. On this device, I did not do the Blowing eFuses” step, and to my surprise, everything worked (SD card and USB keyboard included).

To verify whether my earlier problems were related to v1.1.2 versus the latest release, I wanted to install the same v1.1.2 version on the second device. This is where I think I messed up: I accidentally used the dongle where I had already blown the eFuses, and I re-read the warning:

“DO NOT ATTEMPT THIS STEP UNTIL YOUR DEVICE HAS BEEN FLASHED CORRECTLY, IT WILL PREVENT YOU FROM FLASHING YOUR DEVICE OUTSIDE OF OTA MODE.”

Anyway, I proceeded and got the following output while flashing:

Click Connect to start
Connecting...
Connected successfully.
Try hard reset.
Error: Couldn't sync to ESP. Try resetting.
Connecting...
Connected successfully.
Try hard reset.
Chip type ESP32-S3
Connected to ESP32-S3
MAC Address: 94:A9:90:C8:B9:1C
Uploading stub...
Running stub...
Stub is now running...
Detecting Flash Size
FlashId: 0x1840EF
Flash Manufacturer: ef
Flash Device: 4018
Auto-detected Flash size: 16MB
Image header, Magic=0xAA, FlashMode=0x01, FlashSizeFreq=0x02
Writing data with filesize: 3072
Erase size 3072, blocks 1, block size 0x4000, offset 0x8000, encrypted no
Flashing... 100%
Took 126ms to write 3072 bytes
Erase size 0, blocks 0, block size 0x4000, offset 0x0000, encrypted no
Image header, Magic=0x01, FlashMode=0x00, FlashSizeFreq=0x00
Writing data with filesize: 8192
Erase size 8192, blocks 1, block size 0x4000, offset 0xE000, encrypted no
Flashing... 100%
Took 118ms to write 8192 bytes
Erase size 0, blocks 0, block size 0x4000, offset 0x0000, encrypted no
Image header, Magic=0xE9, FlashMode=0x02, FlashSizeFreq=0x3F
Writing data with filesize: 2284592
Erase size 2284592, blocks 140, block size 0x4000, offset 0x10000, encrypted no
Flashing... 0%
Flashing... 1%
Flashing... 2%
ERROR!
SlipReadError: Timed out waiting for packet header
Image header, Magic=0xE9, FlashMode=0x02, FlashSizeFreq=0x3F
Writing data with filesize: 19488
Erase size 19488, blocks 2, block size 0x4000, offset 0x0000, encrypted no
ERROR!
SlipReadError: Timed out waiting for packet header
Done!
To run the new firmware please reset your device.

Question: Did I brick this device? After a reset/restart, nothing happens. And without working firmware, I don’t think I can use OTA to flash it.

[i-am-shodan]

When you blow the eFuse you can only flash updates via OTA. Why can't you use OTA on your first device?

[i-am-shodan]

What you're describing doesn't line up with what I expect. You shouldn't get any USB device to appear if you force into bootloader mode with the eFuse blown.

What VID and PID does the device have when you plug in with the button held?

OTA is the only way to update the firmware if you have chosen to blow the eFuse.

OTA doesn't verify the firmware is good. You can flash anything including a broken version or an invalid file.

Now if you were to flash with a different platforms code you could get this state where the led is on but nothing is on screen.

[digisaster]

I see this on the details: (when i hold the button on insert)

But how to start a OTA if the device is bricked?

In bootmode the LED is not on, only the backlight.

P.s. Thanks for you patience and responses.

[i-am-shodan]

I would cut your loses now

[digisaster]

Okay, no problem. Can we summarize what this (possibly) means?

• If you apply the efuse blown and still execute via web-flash, the device will become bricked.
  (Yes/No/Need confirmation)
• If you apply the efuse blown, you can still execute part of the flash, but not flash type FlashMode=0x02.
  (Yes/No/Need confirmation)

[digisaster]

Update:

I got the device back running, so it's not bricked. I will make a additional post post how i got it back to life.

[digisaster]

Some update from my side:

I tried the original factory .bin and followed the instructions from this video:
https://www.youtube.com/watch?v=8uFAKa5bIyg

In addition, I visited this page:
https://github.com/Xinyuan-LilyGO/T-Display-S3

From there, I downloaded flash_download_tool_3.9.5.exe and flashed tft_espi_test.bin at address 0x0.

To my surprise, I got the normal test output on the device. After that, I did a complete flash of all the original v1.1.2 files using these settings in the SPIDownloadTool.

And this in the console:

And the device is back to life, so it was not bricked after all. At this stage, I have no idea which step (or steps) caused the problem. There is a small possibility that using a USB-to-USB extension cable was part of the issue, but that’s a wild guess. Anyhow, it’s working again, so the answer to my question is: “No, you did not brick it.”
If someone ever has the same problem, maybe this info can be helpful.

@i-am-shodan
If you want me to run some debug commands on the two devices to check the eFuse state, I’m more than willing to do so.