T-Display S3 AMOLED: monitoring works but can't upload
-
@mshthn The bootloader is indestructible and buried deep in ROM!
Can you show the actual program that caused this?
You say you can still see serial monitor?
Perhaps the sketch BEFORE this last one is hung up?
-Terry -
@teastain2 Yes, I'm sure. That's the only logical conclusion since these messages keep pouring in the monitoring window. I just wonder why I get timeout errors every time I try to upload something.
Unfortunately I don't remember which project was it exactly that broke the board. As I said, this was my first time so I just cloned this repo, and started to uncomment different src_dir lines in platformio.ini.
I remember AdjustBrightness worked, however I couldn't use the slider (touch interface didn't seem to work). Lvgl_images also worked, but I couldn't change to another image for the same reason. LVGL_SD_Images also worked but I didn't have an SD card reader so all I could see was an error message. Fair enough. Then I could restore to Factory.
Now things get a bit blurry here because I panicked and tried a whole bunch of stuff to revive my board. Maybe it was the LumenMeter project that actually broke it. Or the LVGL_Rotation one. Not sure. But apart from changing the src_dir, I didn't do anything with the repo.
-
@mshthn Would it help if I gave you a generic serial test Arduino IDE sketch
This way it does not rely on any libraries.
Once I get this running, I increase the complexity of other more complicated sketches to see what breaks it. -
@teastain2 anything would help a lot. Thank you.
Platformio just tried to refresh itself and failed, so my Windows env is broken now, but I just tried in Linux and it's the same there. Monitoring works, even the device analysis works, but any attempt to upload fails with a timeout error.The crazy thing is that in the analysis I can see the source files, even where a potential div by zero error is happening in the lvgl (lowercase) directory in line 570. I suspect this error makes the board so busy it can't respond.
-
bool ticktock; //declare ticktock as a boolean flag void setup() { //runs once on start up Serial.begin(115200); //open the serial port for USB cable delay(500); } void loop() { //runs in circles! ticktock = !ticktock; //every pass through reverse the flag if (ticktock) { //test current value of the ticktock flag Serial.println("tick"); } else { //prints one or the other to the USB port Serial.println("tock"); } delay(1000); //wait for a second and run again! }Also try Arduino IDE if all else fails.
-
@teastain2 tried it, with Arduino IDE too, still dealing with the same "Write timeout" issue.
In the meantime I visited the troubleshooting page and did a couple of checks. The output of esptool looks good to me:C:\temp>esptool -p COM15 flash_id esptool.py v4.7.0 Serial port COM15 Connecting... Detecting chip type... ESP32-S3 Chip is ESP32-S3 (QFN56) (revision v0.2) Features: WiFi, BLE, Embedded PSRAM 8MB (AP_3v3) Crystal is 40MHz MAC: 74:4d:bd:87:80:e8 Uploading stub... Running stub... Stub running... Manufacturer: ef Device: 4018 Detected flash size: 16MB Flash type set in eFuse: quad (4 data lines) Hard resetting via RTS pin...Tried different USB ports (Type A and C), different cables.
What I'm going to try now is my other Lilygo Amoled board, however I'm a little bit afraid that it'll break it somehow. -
@mshthn Your upload output seems to lack the actual 'writing' phase!
This is the sketch I posted uploaded by Arduino IDESketch uses 258829 bytes (19%) of program storage space. Maximum is 1310720 bytes. Global variables use 18600 bytes (5%) of dynamic memory, leaving 309080 bytes for local variables. Maximum is 327680 bytes. esptool.py v4.5.1 Serial port /dev/cu.usbmodem101 Connecting... Chip is ESP32-S3 (revision v0.1) Features: WiFi, BLE Crystal is 40MHz MAC: [redacted] Uploading stub... Running stub... Stub running... Changing baud rate to 460800 Changed. Configuring flash size... Flash will be erased from 0x00000000 to 0x00003fff... Flash will be erased from 0x00008000 to 0x00008fff... Flash will be erased from 0x0000e000 to 0x0000ffff... Flash will be erased from 0x00010000 to 0x0004ffff... Compressed 15104 bytes to 10430... Writing at 0x00000000... (100 %) Wrote 15104 bytes (10430 compressed) at 0x00000000 in 0.3 seconds (effective 463.0 kbit/s)... Hash of data verified. Compressed 3072 bytes to 146... Writing at 0x00008000... (100 %) Wrote 3072 bytes (146 compressed) at 0x00008000 in 0.1 seconds (effective 396.4 kbit/s)... Hash of data verified. Compressed 8192 bytes to 47... Writing at 0x0000e000... (100 %) Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (effective 585.2 kbit/s)... Hash of data verified. Compressed 259200 bytes to 144153... Writing at 0x00010000... (11 %) Writing at 0x0001daed... (22 %) Writing at 0x00024a12... (33 %) Writing at 0x00029eb2... (44 %) Writing at 0x0002f339... (55 %) Writing at 0x00034ad7... (66 %) Writing at 0x0003dfe1... (77 %) Writing at 0x000451c5... (88 %) Writing at 0x0004a906... (100 %) Wrote 259200 bytes (144153 compressed) at 0x00010000 in 1.6 seconds (effective 1276.8 kbit/s)... Hash of data verified. Leaving... Hard resetting via RTS pin...The 'Hard resetting via RTS pin...' should indicate a successful write and restart of the chip.
-
@teastain2 absolutely lacks. That's because I'm getting the write timeout messages,
To put it short, I think my brand new board is defective. I kind of worked for a while, at least the screen. Nut now I just plugged in the other board (I bought two) and finally I understand why it's called "touch". If I touched the first board I tried never happened anything. This one works.
My theory is that it had a small defect at the beginning and then it got worse as I took in in my hands, plugged in, unplugged, etc.
The smaller (narrower) ribbon wire that goes from the board to the screen (perhaps the touch cable?) is suspicious.
Now the question is, how do I get the screen off to check the wiring?
(Oh btw, sometimes I saw "check your wiring" error messages too!) -
Yeah, the smaller flat ribbon cable is loose. Detached from the connector. Anybody knows how to detach the screen from the board itself?
-
Confirmed. I could get the display off the board without damaging it and it was instantly clear that this cable isn't attached: https://imgur.com/a/iql0GXk
I put the cable back, and nothing changed. Write timeout.
Then I disconnected both cables - to try just the board alone with no screen. Write timeout.
Then I went as low as 9600, then 1200 bits per second. Write timeout.So the board is brand new, it worked for a few days. My theory is that when that cable began to get loose, it badly one of the examples I uploaded. Now it's generating a ton of errors I can see in serial monitor. A permanent storm of errors. It renders the CPU so busy that it can't respond to serial, just pushes out the errors.
So I'd need a hard reset pin, that can wipe the entire memory of the board. Any hints would be appreciated.
