The device turned off and appeared to flash, the Chrome upload utility reported no errors and showed the file upload as it progressed. After upload it starts up, but the device is still running 0.9.10. I confirmed that it is just a typo because I do not see multi-byte options in the advert part of mgmt menu. It also still has upgrading its own firmware over wifi broken.
I tried reflashing three times and have found the same result. The file has the correct checksum, there is no 0.9.10 firmware that exists for me to have selected incorrectly on the computer, and I see no errors.
Additional context
I do not understand how this is possible, the checksum from the 0.9.10 firmware is different so I do not have the wrong file. I have programmed many ESP32 devices and have never seen the flasher say it completes successful and reboot only to not have upgraded the firmware. This is the only firmware file in the folder, and the web flasher file name clearly said 0.9.11.
I have not tried erasing the device or using the -merged versions, as both would delete my settings as I understand them to work.
**Describe the bug**
Web Flasher not upgrading 0.9.10 to 0.9.11 despite giving no issues during flashing.
**Which device are you using**
LilyGO T-Deck
**Which Firmware are you using**
0.9.10, though I expected 0.9.11
**To Reproduce**
Steps to reproduce the behavior:
1. I downloaded the firmware firmware_tdeckplus_v0.9.11.bin
2. I used sha256sum firmware_tdeckplus_v0.9.11.bin and it gave the correct checksum and filename.
3. I used the Chrome web flasher at https://flasher.meshcore.co.uk/ using custom firmware to select the firmware image.
4. The device turned off and appeared to flash, the Chrome upload utility reported no errors and showed the file upload as it progressed. After upload it starts up, but the device is still running 0.9.10. I confirmed that it is just a typo because I do not see multi-byte options in the advert part of mgmt menu. It also still has upgrading its own firmware over wifi broken.
5. I tried reflashing three times and have found the same result. The file has the correct checksum, there is no 0.9.10 firmware that exists for me to have selected incorrectly on the computer, and I see no errors.
**Additional context**
I do not understand how this is possible, the checksum from the 0.9.10 firmware is different so I do not have the wrong file. I have programmed many ESP32 devices and have never seen the flasher say it completes successful and reboot only to not have upgraded the firmware. This is the only firmware file in the folder, and the web flasher file name clearly said 0.9.11.
I have not tried erasing the device or using the -merged versions, as both would delete my settings as I understand them to work.
<!-- github-sync-id:4097728575 -->
No, I'm afraid your post is the first I've heard of it. It's strange, I have made custom PCBs with these ESP32 chips on them and everything about the programming step looks successful.
The file definitely looks correct from the checksum and the 0.9.10 firmware isn't present on the disk.
I select the device from the dropdown menu and get this output from the virtual terminal.
esptool.js
Serial port WebSerial VendorID 0x303a ProductID 0x1001
Connecting...
Detecting chip type... ESP32-S3
Chip is ESP32-S3 (QFN56) (revision v0.2)
Features: Wi-Fi,BLE,Embedded PSRAM 8MB (AP_3v3)
Crystal is 40MHz
MAC: 3c:dc:75:40:6d:40
Uploading stub...
Running stub...
Stub running...
Manufacturer: 46
Device: 4018
Detected flash size: 16MB
Compressed 2043440 bytes to 1363936...
Writing at 0x10000... (1%)
Writing at 0x18418... (2%)
Writing at 0x1f113... (3%)
Writing at 0x23816... (4%)
Writing at 0x2fefd... (5%)
Writing at 0x3c4a6... (7%)
Writing at 0x4b005... (8%)
Writing at 0x5575c... (9%)
Writing at 0x615a5... (10%)
Writing at 0x6a56a... (11%)
Writing at 0x6fa25... (13%)
Writing at 0x75496... (14%)
Writing at 0x7a625... (15%)
Writing at 0x7fa05... (16%)
Writing at 0x84c9d... (17%)
Writing at 0x89ef8... (19%)
Writing at 0x8ef3b... (20%)
Writing at 0x949f6... (21%)
Writing at 0x9a4f7... (22%)
Writing at 0x9f7b6... (23%)
Writing at 0xa4da7... (25%)
Writing at 0xaa2e6... (26%)
Writing at 0xafdee... (27%)
Writing at 0xb502e... (28%)
Writing at 0xba5b5... (29%)
Writing at 0xbfe5a... (30%)
Writing at 0xc530a... (32%)
Writing at 0xcab89... (33%)
Writing at 0xd0911... (34%)
Writing at 0xd5a41... (35%)
Writing at 0xdb5ad... (36%)
Writing at 0xe150a... (38%)
Writing at 0xe6f02... (39%)
Writing at 0xec987... (40%)
Writing at 0xf249f... (41%)
Writing at 0xf814b... (42%)
Writing at 0xfd2ab... (44%)
Writing at 0x1023f1... (45%)
Writing at 0x107370... (46%)
Writing at 0x10c333... (47%)
Writing at 0x111306... (48%)
Writing at 0x116893... (50%)
Writing at 0x11c456... (51%)
Writing at 0x121755... (52%)
Writing at 0x126c16... (53%)
Writing at 0x12bd26... (54%)
Writing at 0x1318bd... (55%)
Writing at 0x136961... (57%)
Writing at 0x13c89c... (58%)
Writing at 0x142093... (59%)
Writing at 0x147e5a... (60%)
Writing at 0x14d1a1... (61%)
Writing at 0x152d67... (63%)
Writing at 0x1590d8... (64%)
Writing at 0x15f63d... (65%)
Writing at 0x164ea0... (66%)
Writing at 0x169d8d... (67%)
Writing at 0x16f243... (69%)
Writing at 0x1747b5... (70%)
Writing at 0x179e7d... (71%)
Writing at 0x17f529... (72%)
Writing at 0x184585... (73%)
Writing at 0x189572... (75%)
Writing at 0x18e303... (76%)
Writing at 0x193ede... (77%)
Writing at 0x1993e9... (78%)
Writing at 0x19e58c... (79%)
Writing at 0x1a3641... (80%)
Writing at 0x1a858c... (82%)
Writing at 0x1ad6af... (83%)
Writing at 0x1b2788... (84%)
Writing at 0x1b7bc5... (85%)
Writing at 0x1bce81... (86%)
Writing at 0x1c2cb6... (88%)
Writing at 0x1c83b0... (89%)
Writing at 0x1cdef7... (90%)
Writing at 0x1d32c1... (91%)
Writing at 0x1d9ca5... (92%)
Writing at 0x1e2216... (94%)
Writing at 0x1ea334... (95%)
Writing at 0x1f0a73... (96%)
Writing at 0x1f5b5e... (97%)
Writing at 0x1fb6d6... (98%)
Writing at 0x20147d... (100%)
Wrote 2043440 bytes (1363936 compressed) at 0x10000 in 12.092 seconds.
Leaving...
Hard resetting via RTS pin...
While it is writing I see the display turn off as expected, and I see it turn back on after the Hard resetting message.
However, the title screen firmware is somehow still 0.9.10 and the new multi-byte prefixes don't exist in the management advert section. It also still has the bug from 0.9.10 that makes wifi upgrades fail.
I am not sure how this is possible to be honest, it is 2MBytes of code so I'm imagining there is a SPI Flash Memory in there and I know the ESP32 can memory map those. I did try to "export" my config so I can erase the flash and use the merged versions and perhaps recover my configuration, I used the bluetooth connection to the phone app.
It might be a flasher bug but it sure looks like it thinks everything works.
No, I'm afraid your post is the first I've heard of it. It's strange, I have made custom PCBs with these ESP32 chips on them and everything about the programming step looks successful.
The file definitely looks correct from the checksum and the 0.9.10 firmware isn't present on the disk.
```
$ sha256sum firmware_tdeckplus_v0.9.11.bin
6a7ed1508a60ad861bff8d7a836736f1fc7dd44fd920e992153d73d3386a6440 firmware_tdeckplus_v0.9.11.bin
```
The flasher at https://flasher.meshcore.co.uk/ shows this after I tell it which custom firmware to flash.
<img width="807" height="601" alt="Image" src="https://github.com/user-attachments/assets/b30f6976-d2f1-4053-ae03-8a6a4bf5f97c" />
I select the device from the dropdown menu and get this output from the virtual terminal.
```
esptool.js
Serial port WebSerial VendorID 0x303a ProductID 0x1001
Connecting...
Detecting chip type... ESP32-S3
Chip is ESP32-S3 (QFN56) (revision v0.2)
Features: Wi-Fi,BLE,Embedded PSRAM 8MB (AP_3v3)
Crystal is 40MHz
MAC: 3c:dc:75:40:6d:40
Uploading stub...
Running stub...
Stub running...
Manufacturer: 46
Device: 4018
Detected flash size: 16MB
Compressed 2043440 bytes to 1363936...
Writing at 0x10000... (1%)
Writing at 0x18418... (2%)
Writing at 0x1f113... (3%)
Writing at 0x23816... (4%)
Writing at 0x2fefd... (5%)
Writing at 0x3c4a6... (7%)
Writing at 0x4b005... (8%)
Writing at 0x5575c... (9%)
Writing at 0x615a5... (10%)
Writing at 0x6a56a... (11%)
Writing at 0x6fa25... (13%)
Writing at 0x75496... (14%)
Writing at 0x7a625... (15%)
Writing at 0x7fa05... (16%)
Writing at 0x84c9d... (17%)
Writing at 0x89ef8... (19%)
Writing at 0x8ef3b... (20%)
Writing at 0x949f6... (21%)
Writing at 0x9a4f7... (22%)
Writing at 0x9f7b6... (23%)
Writing at 0xa4da7... (25%)
Writing at 0xaa2e6... (26%)
Writing at 0xafdee... (27%)
Writing at 0xb502e... (28%)
Writing at 0xba5b5... (29%)
Writing at 0xbfe5a... (30%)
Writing at 0xc530a... (32%)
Writing at 0xcab89... (33%)
Writing at 0xd0911... (34%)
Writing at 0xd5a41... (35%)
Writing at 0xdb5ad... (36%)
Writing at 0xe150a... (38%)
Writing at 0xe6f02... (39%)
Writing at 0xec987... (40%)
Writing at 0xf249f... (41%)
Writing at 0xf814b... (42%)
Writing at 0xfd2ab... (44%)
Writing at 0x1023f1... (45%)
Writing at 0x107370... (46%)
Writing at 0x10c333... (47%)
Writing at 0x111306... (48%)
Writing at 0x116893... (50%)
Writing at 0x11c456... (51%)
Writing at 0x121755... (52%)
Writing at 0x126c16... (53%)
Writing at 0x12bd26... (54%)
Writing at 0x1318bd... (55%)
Writing at 0x136961... (57%)
Writing at 0x13c89c... (58%)
Writing at 0x142093... (59%)
Writing at 0x147e5a... (60%)
Writing at 0x14d1a1... (61%)
Writing at 0x152d67... (63%)
Writing at 0x1590d8... (64%)
Writing at 0x15f63d... (65%)
Writing at 0x164ea0... (66%)
Writing at 0x169d8d... (67%)
Writing at 0x16f243... (69%)
Writing at 0x1747b5... (70%)
Writing at 0x179e7d... (71%)
Writing at 0x17f529... (72%)
Writing at 0x184585... (73%)
Writing at 0x189572... (75%)
Writing at 0x18e303... (76%)
Writing at 0x193ede... (77%)
Writing at 0x1993e9... (78%)
Writing at 0x19e58c... (79%)
Writing at 0x1a3641... (80%)
Writing at 0x1a858c... (82%)
Writing at 0x1ad6af... (83%)
Writing at 0x1b2788... (84%)
Writing at 0x1b7bc5... (85%)
Writing at 0x1bce81... (86%)
Writing at 0x1c2cb6... (88%)
Writing at 0x1c83b0... (89%)
Writing at 0x1cdef7... (90%)
Writing at 0x1d32c1... (91%)
Writing at 0x1d9ca5... (92%)
Writing at 0x1e2216... (94%)
Writing at 0x1ea334... (95%)
Writing at 0x1f0a73... (96%)
Writing at 0x1f5b5e... (97%)
Writing at 0x1fb6d6... (98%)
Writing at 0x20147d... (100%)
Wrote 2043440 bytes (1363936 compressed) at 0x10000 in 12.092 seconds.
Leaving...
Hard resetting via RTS pin...
```
While it is writing I see the display turn off as expected, and I see it turn back on after the Hard resetting message.
However, the title screen firmware is somehow still 0.9.10 and the new multi-byte prefixes don't exist in the management advert section. It also still has the bug from 0.9.10 that makes wifi upgrades fail.
I am not sure how this is possible to be honest, it is 2MBytes of code so I'm imagining there is a SPI Flash Memory in there and I know the ESP32 can memory map those. I did try to "export" my config so I can erase the flash and use the merged versions and perhaps recover my configuration, I used the bluetooth connection to the phone app.
It might be a flasher bug but it sure looks like it thinks everything works.
<!-- github-comment-id:4088388207 -->
The -merged version that erases my flash succeeded.
I exported my settings to my phone, flashed the merged version, and imported the settings to my t-deck from the phone.
I cannot guess what this means, other than that perhaps the non-merged version has an issue.
The -merged version that erases my flash succeeded.
I exported my settings to my phone, flashed the merged version, and imported the settings to my t-deck from the phone.
I cannot guess what this means, other than that perhaps the non-merged version has an issue.
<!-- github-comment-id:4101817791 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Describe the bug
Web Flasher not upgrading 0.9.10 to 0.9.11 despite giving no issues during flashing.
Which device are you using
LilyGO T-Deck
Which Firmware are you using
0.9.10, though I expected 0.9.11
To Reproduce
Steps to reproduce the behavior:
Additional context
I do not understand how this is possible, the checksum from the 0.9.10 firmware is different so I do not have the wrong file. I have programmed many ESP32 devices and have never seen the flasher say it completes successful and reboot only to not have upgraded the firmware. This is the only firmware file in the folder, and the web flasher file name clearly said 0.9.11.
I have not tried erasing the device or using the -merged versions, as both would delete my settings as I understand them to work.
I had this issue when I had the M5 launcher installed. Could that be your problem, too?
No, I'm afraid your post is the first I've heard of it. It's strange, I have made custom PCBs with these ESP32 chips on them and everything about the programming step looks successful.
The file definitely looks correct from the checksum and the 0.9.10 firmware isn't present on the disk.
The flasher at https://flasher.meshcore.co.uk/ shows this after I tell it which custom firmware to flash.
I select the device from the dropdown menu and get this output from the virtual terminal.
While it is writing I see the display turn off as expected, and I see it turn back on after the Hard resetting message.
However, the title screen firmware is somehow still 0.9.10 and the new multi-byte prefixes don't exist in the management advert section. It also still has the bug from 0.9.10 that makes wifi upgrades fail.
I am not sure how this is possible to be honest, it is 2MBytes of code so I'm imagining there is a SPI Flash Memory in there and I know the ESP32 can memory map those. I did try to "export" my config so I can erase the flash and use the merged versions and perhaps recover my configuration, I used the bluetooth connection to the phone app.
It might be a flasher bug but it sure looks like it thinks everything works.
The -merged version that erases my flash succeeded.
I exported my settings to my phone, flashed the merged version, and imported the settings to my t-deck from the phone.
I cannot guess what this means, other than that perhaps the non-merged version has an issue.