Problem with boot mode on T-Deck

[bryanlyon]

I have 3 t-decks. Unfortunately one of them corrupted during a download, since then I have been unable to get it to take an new firmware.

I can (sometimes) get it to boot into the rom bootloader mode by holding down the trackball while resetting, however, once I try to use the esptool it finds the com port, but times out in writing.

esptool.py v4.5.1
Serial port /dev/ttyACM0
Connecting....

A serial exception error occurred: Write timeout

I have tried this also on other computers with identical results. I've also tried putting my working T-decks into bootloader mode and while I can get them to bootloader mode the results are identical to my failed T-Deck.

The good ones will still take updated firmware while running normally, but the failed T-Deck will not, as it continually resets the USB connection.

With trace enabled in esptool I get the following:

esptool.py v4.6.2
Serial port /dev/ttyACM0
Connecting...TRACE +0.000 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
    0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
    5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
    55555555                          | UUUU
TRACE +0.000 Write 46 bytes: 
    c000082400000000 0007071220555555 | ...$........ UUU
    5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
    5555555555555555 5555555555c0     | UUUUUUUUUUUUU.


A serial exception error occurred: Write timeout

I've tried forcing the chip with --chip esp32s3 (and esp32) as well as various baud rates. Everything I try fails with the write timeout.

Connection is successful and I get data from the chip when I do:

[Fri Jul 21 10:05:03 2023] usb 1-2.4: new full-speed USB device number 95 using xhci_hcd
[Fri Jul 21 10:05:03 2023] usb 1-2.4: New USB device found, idVendor=303a, idProduct=1001, bcdDevice= 1.01
[Fri Jul 21 10:05:03 2023] usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Fri Jul 21 10:05:03 2023] usb 1-2.4: Product: USB JTAG/serial debug unit
[Fri Jul 21 10:05:03 2023] usb 1-2.4: Manufacturer: Espressif
[Fri Jul 21 10:05:03 2023] usb 1-2.4: SerialNumber: 34:85:18:A6:34:44
[Fri Jul 21 10:05:03 2023] cdc_acm 1-2.4:1.0: ttyACM0: USB ACM device

But any attempt to write or to erase the flash fails with a write timeout.

This is reproducable on all 3 of my T-Decks when in bootloader mode (and on multiple computers), but like I said, 2 of them can get flashed normally in the non-bootloader mode.

[bkircher67]

I have the same issues. erase_flash works fine on T-HMI and on T-Display-S3 but the T-Desk either times out (non bootloader mode) or stalls (bootloader mode by pressing the trackball-button). I also tried it under Windows 11 and on MacOS.
I only once was able to install Micropython .. probably this bricked my T-Desk.

[lewisxhe]

Try this method!

https://github.com/Xinyuan-LilyGO/T-Deck/tree/master/firmware

[bryanlyon]

Unfortunately the linked instructions are the ones I've already followed and does not make bootloader mode work on the T-deck. I am still unable to flash when the T-Deck is in bootloader mode on any of my devices.

[lewisxhe]

Please take a photo of the PCB on ESP32S3 and show it to me.

[bkircher67]

Hello, I tried all kinds of setting on the Windows Flasher, but I always see the same behaviour:
If not in bootloader-mode (on COM5): it just runs forever

test offset :  0 0x0
case ok
.................................................................................................................................................................................

if in bootload-mode (COM4 or COM7): it waits some seconds and returns with a message box saying:

2-sync fail: 
Tips: Please refer to the chip dataset and confirm that strapping pin's status is correct.

KInd regards
Bernd

[bkircher67]

Here's my PCB:

[bryanlyon]

Here is mine.

[lewisxhe]

Please try to remove D2

[bkircher67]

Thanks!

Removing D2 worked perfectly fine for me! Uploading new firmware is no longer a problem.

Kind regards

Bernd

[MrSniffer]

I just received two T-Decks with the D2 jumper. Should they be removed in all cases? Kindly explain before I have the same problem.

[RevClamJuice]

Can confirm. i was having the same problem and removing D2 fixed it.

[karfas]

Had the very same problem.
Removing D2 works to use simple commands like chip_id.
However, I had to upgrade to esptool.py v4.7-dev (direct from the github repo) to get erase_flash etc. working.

[YAMLcase]

Wow, talk about fast fix to the production line: I just received two T-Decks ordered 2 weeks ago and notice D2 is not installed on either. I don't see any version info on the PCB though, is there any way to tell the difference?

[danjperron]

Ok So I got a boot load problem and I did figure it out. The ESP32-S3 need to have GPIO0 and GPIO46 to 0 to go into the boot load mode but the ESP32-C3 int is connected to the GPIO46 and disturb the very high resistor pull down value.

So shorting the GPIO46 and the same time that I press the GPIO0 button , then press the reset and release both GPIO0 and GPIO46 does the trick. This tooks me 2 evenings to figure out why the T DecK didnt want to go to boot load. Im sure I`m not the only one with this problem.

[Freyr86]

Name of God thank you for this answer I've been looking for a solution for 3 days

[sonic2wb]

THANK YOU THANK YOU, fixed my issue uploading code. removing D2.