Hyperpixel 3.5 not working properly on Pi4
Closed this issue · 5 comments
Hi,
I try to use my Hyperpixel 3.5 Display (I need to use this smaller version to fit for a project) on a Pi4 with Raspbian Buster (latest version and updates). It is only working from time to time.
I installed it by using the setup.sh of the branch for pi4 as mentioned in the description. The service for touch is not starting.
pi@RPi-IT:~ $ systemctl status hyperpixel-touch.service hyperpixel-touch.service - Hyperpixel LCD Touch Screen Driver Daemon Loaded: loaded (/usr/lib/systemd/system/hyperpixel-touch.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2020-02-25 16:17:06 GMT; 5min ago Process: 370 ExecStart=/usr/bin/hyperpixel-touch (code=exited, status=0/SUCCESS) Main PID: 382 (code=exited, status=1/FAILURE)
Feb 25 16:17:06 RPi-IT systemd[1]: hyperpixel-touch.service: Service RestartSec=100ms expired, scheduling restart. Feb 25 16:17:06 RPi-IT systemd[1]: hyperpixel-touch.service: Scheduled restart job, restart counter is at 5. Feb 25 16:17:06 RPi-IT systemd[1]: Stopped Hyperpixel LCD Touch Screen Driver Daemon. Feb 25 16:17:06 RPi-IT systemd[1]: hyperpixel-touch.service: Start request repeated too quickly. Feb 25 16:17:06 RPi-IT systemd[1]: hyperpixel-touch.service: Failed with result 'exit-code'. Feb 25 16:17:06 RPi-IT systemd[1]: Failed to start Hyperpixel LCD Touch Screen Driver Daemon.
From time to time the display is working without issues. But about 99% of the time it is not and just shows a pixelish bar at the bottom. No changes were made when it starts/stops working, just doing reboots.
Can anybody help me here? It would be great if I can use it on my pi4. It is working great on my pi3 btw.
Thanks
Marius
Feb 25 16:17:06 RPi-IT systemd[1]: hyperpixel-touch.service: Service RestartSec=100ms expired, scheduling restart.
Feb 25 16:17:06 RPi-IT systemd[1]: hyperpixel-touch.service: Scheduled restart job, restart counter is at 5.
-- Subject: Automatic restarting of a unit has been scheduled
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- Automatic restarting of the unit hyperpixel-touch.service has been scheduled, as the result for
-- the configured Restart= setting for the unit.
Feb 25 16:17:06 RPi-IT systemd[1]: Stopped Hyperpixel LCD Touch Screen Driver Daemon.
-- Subject: A stop job for unit hyperpixel-touch.service has finished
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- A stop job for unit hyperpixel-touch.service has finished.
-- The job identifier is 273 and the job result is done.
Feb 25 16:17:06 RPi-IT systemd[1]: hyperpixel-touch.service: Start request repeated too quickly.
Feb 25 16:17:06 RPi-IT systemd[1]: hyperpixel-touch.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- The unit hyperpixel-touch.service has entered the 'failed' state with result 'exit-code'.
Feb 25 16:17:06 RPi-IT systemd[1]: Failed to start Hyperpixel LCD Touch Screen Driver Daemon.
-- Subject: A start job for unit hyperpixel-touch.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- A start job for unit hyperpixel-touch.service has finished with a failure.
Okay it looks like the init service is not starting from time to time. I can start it manually with systemctl and then it is working. I just changed the loglevel of systemd to debug and try to get more detailed information.
I just did two starts of the Pi. No changes done between the starts.
First startup -> display not working
Second startup -> display working
At both times the status of hyperpixel-init says only "loaded", but not active. Journalctl is looking exactly the same at both starts. I don't get it...
Any ideas what else I could check?
I have a workaround for now using a systemd timer that waits 5 seconds after boot to start the hyperpixel-init.service. Looks like there is some kind of timing issue?
@Counterdoc a timing issue makes sense- although I'm not sure why this should be the case. The Pi 4 is faster, certainly, but I don't think the hyperpixel-init.service depends on anything that wont have started.
Could it, perhaps, be clashing with hyperpixel-touch.service? I believe some pins are shared between the two services, so this could be a race condition.