M5Paper reboot-persistent touchscreen failure (under UIFlow)

Nili

I have three M5Paper running the same little UIFlow app which uses ESPNow to Broadcast touch data.

The first issue is that with high broadcast frequency a few of the broadcasted messages tend to get buffered but not sent. They seem to get sent when the app broadcasts the next message which is postponed in return. So there seems a buffer index problem. Might be some semaphore lock missing. Since I don't know if that system employ any kind of server (while it shouldn't) I can't pin the real origin of this problem.

Now, the more serious problem, and I don't know if that results from that buffer index bug, is that two of the three devices tend to loose their touch screen functionality. This even stays that way after a reboot, power down or re-download of the app. The touchscreen is dead. The only solution to revive it so far is to re-flash UIFlow or any other Flash-Package. Not sure if the UIFlow/MicroPython memory gets overwritten or something, but it's pretty work-intensive reviving the device with M5Burner and re-download of the app.

Interestingly it seems to be the same two of the three Papers showing that failure while a single one performs normal all the time. Which makes the whole thing feel even stranger.

Anyone else with dead touch sensors until re-flashing?

felmue

Hello @Nili

are you running the M5Paper from battery or USB? Does that make a difference?
have you considered a simpler UIFlow app which only uses touch (and no ESPNow)?

If you suspect a hardware failure I'd suggest installing the factory test firmware and check if you loose touch with that as well.

Thanks
Felix

ajb2k3

The firmware is marked as ALPHA Test which means that its not fully working.
Make a list of all issues and file a bug report.
Just be aware that its Chinese new year and the firmware was rushed out beforehand.

Nili

Ok, so I found that a reset (Paper plugged in and power button is pressed) resets the touch screen. Might be great to have a similar full reset on reboot.

Anybody knows what the power blocks in UIFlow (extern and main power on off) and from which state one could use Power On? I'll see if any of those could be used as a reset workaround for the touch screen?

I also added a few debugging lines to confirm that the touch is actually not working and I don't crash the loop. Loop still loops, just touch shuts down/gets unresponsive.

@ajb2k3 said in M5Paper reboot-persistent touchscreen failure (under UIFlow):

The firmware is marked as ALPHA Test which means that its not fully working.

I know.

Make a list of all issues and file a bug report.

Where would I post that report? I thought this might be the place. (Edit: found it. Under Software :)

Just be aware that its Chinese new year and the firmware was rushed out beforehand.

I know. Happy to have it with the device at all.

@felmue said in M5Paper reboot-persistent touchscreen failure (under UIFlow):

have you considered a simpler UIFlow app which only uses touch (and no ESPNow)?

No. That ESPNow part is the actual fun part. Could use another transfer protocol. Still, it should not go out of sync nor kill the touchscreen while doing so :) My actual problem is that a normal reboot does leave it disabled. That should not be the case.

If you suspect a hardware failure I'd suggest installing the factory test firmware and check if you loose touch with that as well.

Well, you would only know if the same triggers are triggered. And since a full reset or firmware update (with a full reset) revives it...

felmue

Hello @Nili

I am sorry, I guess I wasn't clear. What I meant is a simpler UIFlow app (w/o ESPNow) only for testing purposes to see if the issue happens over time as well.

Re UIFlow M5Paper power blocks:
If you looks at the sticker on the back of M5Paper you'll see three digital switches (labelled MOS). One is for everything (main) except RTC, one is for the ePaper (epd) and one is for the external 5 volts (extern) ports A, B and C. Unfortunately there is no such switch for the touch - it is powered whenever the main switch is on.

A possible workaround (untested) could be to shutdown M5Paper and wake it up through the RTC by using the block 'Restart after seconds'. That should turn the main switch (and with that the touch) off and then on again from the RTC.

Cheers
Felix

Nili

@felmue

Hey, thanks for the explanation. Sorry for the late reply.

After adding a third Paper, it shows that the receiver queue, not the sender get's async and will deliver old messages. This might also lead to some buffer overflow or event queue problem. Still, the fact that a simple power-cycle on battery power does not revive the touch controller seems, um, not ideal.

I'll try the power blocks for other things after your great explanation. Thanks again. Where did you get that info from, btw, I really tried to find docs about it. I enjoyed the diagram method, though :)

felmue

Hi @Nili

while reading the touch IC (GT911) documentation I found that there is a mechanism which allows to select which of two I2C addresses should be used. Depending on how the touch INT line is driven by the ESP32 (low or high) when the reset line goes back to high, either I2C address gets selected.

But since the touch INT line is connected to GPIO36 of the ESP32 and GPIO36 is an input only GPIO the ESP32 cannot drive it. From the ESP32 documentation:

GPIO34-39 can only be set as input mode and do not have software pullup or pulldown functions.

I further found that the 10k pull-up resistor (R87) on the touch INT line, listed in the schematics, is not populated in my M5Paper. I guess this mean when the touch IC is not driving the INT line it is floating and the touch IC could end up with either I2C address.

Now, in the GT911 library I found the following code in function begin() which I tries to figure out which I2C address the touch IC actually started up with:

    Wire.beginTransmission(0x14);
    if (Wire.endTransmission())
    {
        Wire.beginTransmission(0x5D);
        if (Wire.endTransmission())
        {
            log_e("Touch screen IIC connection error");
            return ESP_FAIL;
        }
        _iic_addr = 0x5D;
    }

I wonder if that auto detect mechanism fails sometimes leaving the touch IC with one I2C address and the ESP32 trying to talk to it with the other?

Thanks
Felix