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

I get a new API key on the M5Paper when I erase it (edit: using the erase button in the upper right of M5Burner) and then burn the firmware again. Would be easier to have a working button, though :)

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

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?