M5Paper reboot-persistent touchscreen failure (under UIFlow)



  • 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?



  • 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



  • 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.



  • 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...



  • 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



  • @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 :)