the display stops responding

[graziel666]

as the tittle says, i noticed that after some inactivity time, the keyboard stops responding (on the t-deck) but i can still type using serial with screen (on this stage, the t-deck inputs dont show on the t-deck display, but the serial console inputs from my computer show just fine)
but after a little more time (around 3 or 4 mins) the display stops responding completely

i keep seeing the t-deck keyboard input on the the serial console, in fact typing exit and enter just close repl and it reloads normally, or ctrl + D from my pc

[RetiredWizard]

Thanks! I'll try and reproduce, what version of CircuitPython are you running?

[RetiredWizard]

I installed CircuitPython 9.0.4 and the tdeck_repl files. After starting the repl and connecting a usb serial terminal, I waited a little more than 10 minutes and the keyboard was still working.

Are you running any commands from either the terminal window or the tdeck keyboard before letting the device sit inactive? How long do you leave the device in active? Is the issue repeatable? If so, what are the exact steps you're taking before the issue occurs?

[RetiredWizard]

I did find a bug in the playi2s applet, it wasn't properly loading the "input" overload so once playi2s was imported, only the usb uart (terminal screen) and not the t-deck keyboard would work until the applet was exited. If you're running python code you will run into the same issue if your code doesn't include the following block before executing any input statements:

    try:
        from tdeck_repl import input
    except:
        pass

[graziel666]

sorry for the late just saw the asnwers, i did noticed that bug on playi2s and did the same things you said here
the only other code i running is from virtcode.py and one i made to clear the screen, it's just a print("\n" * 20)

last night i noticed that before happening i was getting the code stopping for an autoreload, so i just did
import supervisor supervisor.runtime.autoreload = false
to disable the autoreaload, and it makes it happen less frequently, but sadly i dont see any other error when this happen, and the only way to replicate it is just waiting

the only thing i can think on is maybe a difference between running it from battery and usb? rn i'm just using the usb port to power it on and i wont have a battery for a long time

edit: just saw you asked, it happens either way if i use a command, write random things or just turn it on and let it sit, after a random amount of time (longer now after disabling autoreload) the display just stops responding and keep showing the last thing on it, it's like is just frozen, but the t-deck keyboard inputs still work, in fact i'm able to reload repl from there, i just can't see what i'm typing until repl reloads

[RetiredWizard]

Good call on the power issues, I disconnected the Lipo battery from my board and reproduced the issue pretty quickly. You properly explained this but I misunderstood, It's actually the screen that stops working not the keyboard. DOH 😁

This is also definitely related to the auto-reload...

The screen is actually managed by the core, so it may take some digging to figure this one out.

By the way, here's another approach to clearing the screen:
print(chr(27)+"[2J")

[RetiredWizard]

I just reproduced the issue with the battery connected by forcing an auto-reload. It's not related to the power source after all...

[RetiredWizard]

Something is blocking the auto-reload.

I'm assuming that the supervisor.runtime.autoreload = false command you're entering isn't remaining in effect or has some other issue. When you have that command entered and the problem shows up, try typing exit and let me know if that causes and Auto-reload message to occur.

[RetiredWizard]

My current theory is that the tdeck_repl code is getting run before the board has fully initialized the I2C bus after a restart and that's causing the restart to hang before the display is initialized. It's a little tough to diagnose though because I can sometime reproduce the issue and then it seems to fix itself.

I'll pick this up later but in the mean time, if you could try adding time.sleep(5) as the first line of __init__ in tdeck_repl.py I'd be curious if that resolved the issue for you. If it does, you could try reducing the delay to 2 or 1 seconds.

During my testing it also appeared that adding a print statement to the try/except block at line 53 of tdeck_repl.py made a difference. I replaced the existing block with:

                    try:
                        i2c.readinto(self._key)
                    except Exception as err:
                    	print(f'Caught {err}')
                        self._key=bytearray(1)

[graziel666]

i'm very happy i explained properly, english is not my main language and i have a horrible time trying to explain myself sometimes hahha
i made the changes you said, now is time to wait

using exit just kills repl and give me the promp to press a key or ctrl-D
there the keyboard doesn't work, but i assume this is normal since it was happening before too, and it just jumps back up after pressing ctrl-D to make a soft reboot

i did add a command to code.py to make a reset

            __cmd += ("\n" + ("    " if __line != "" else "") + __line)
        else:
            if __line.lower() == 'exit':
                break
            __cmd = __line
            if __line.lower() == 'reset':
                supervisor.reload()
            __cmd = __line```
            
that's how i was fixing the issue for now

[RetiredWizard]

using exit just kills repl and give me the promp to press a key or ctrl-D
there the keyboard doesn't work, but i assume this is normal since it was happening before too, and it just jumps back up after pressing ctrl-D to make a soft reboot

Along with the press a key message does it say anything about auto-reload?

[graziel666]

nope, just code running, press any key to start repl or ctrl-D to reload

[RetiredWizard]

Auto-reload may be a dead-end, time to look at the core display functions....

[graziel666]

at least on these last 22 mins since my first message, it's working just fine after adding the delay

[RetiredWizard]

Hmm, I had talked myself out of that being an effective workaround. Let me know if you do have any screen hangs using the delay.

[graziel666]

well, until now i was just doing random things, mainly making errors with playi2s and just printing random things on loop, and it held up perfectly fine
so i'd say that delay fixed it
it was either that or the change to tdeck_repl.py on line 53