New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Touchscreen fails to connect at boot (Pi 4) #41
Comments
Does it work reliably when it does init? Looks like it could be a connectivity issue, but this isn't something I've seen before. |
Yeah, works perfectly unless I reboot. I've used it handheld for at least a couple hours with zero issues. Reboot, and it fails to init again. |
I am seeing the same error, and touchscreen failure. Will retry once the device has cooled down. I have tried both the installs via |
It didn't take long to cool down, and the touchscreen works on boot (well, touch events happen, they're just in completely the wrong place on the screen! But that's the next problem) |
I can confirm that, if the the screen is a bit hot, and you reboot it sometimes, you could be out of luck and have no touchscreen. Only solution is to cool it down and then cold boot ? |
ps. i assume now that the malfunction of touch function is heat related, because i tried to reboot some times with a machine that was just started and then it works fine |
I found this in the log: |
Hi, I did some testing: on RbPi 4 with the latest release of Rasp. full version: I've tried to find out why the display was working during boot and not restart, and I can conclude that it has definitly something to do with the heath of the display, because i've tried like 20 reboots with and without an extra fan (external powersupply , so just for airflow) and the number of times that i restarted the Pi with an airflow for cool air, was like 0 times that i could not access the system via touchscreen after an reboot, against 18 times that I could not access the system via the display even my pi was not warmer then 50 degrees celcius. I dont know if this is the case with rbpi 3 too ? |
@R0B3RDV would these latest findings conclude that it's less related to heat and more related to some other issue with the display? I run my tests on a Pi which I tore the heat spreader off and now have poorly coupled to one of our big metal heatsink cases. It runs hot, albeit our ambient air temperature is not particularly extreme, so I might have expected to see some indication of this failure. I can definitely try to overheat a display and see what happens, though. It might be worth probing the i2c bus during this failure condition and seeing what you can see. Touch runs over a soft i2c bus Based on the assumption that it'll be 3, you can then probe the bus with
|
i will shortly update some more info if you like, but i've upgraded the raspberry pi 4 now with a ninja coupe, (i had a passive cooler but i now replaced it with the active fanshim - without installing the fanshim drivers offcouse), installed the display ontop and working as a breeze now! :) with the passive cooler, i was thinking that maybe a particular place on the bottom of the screen was getting to warm, but so, i wasnt even using the board... |
but now i am having no trouble rebooting etc even after some while, no touchscreen malfunctions etc. I even tried to reverse the fan, passive fan ontop of the chip so that the airflow is to the bottom side of the screen and the chips are getting the warm air sucked away via passive and partly active cooling. |
I've been running some tests of my own to see if I can replicate. If you have another failure condition, can you tell me what you see if you run:
You should see something like:
|
I am having the same problem with a Hyperpixel 4.0 Square on a PI zero W running Rasbian stretch:
Any update on this? EDIT: Sorry, I had an old overlay for the standard sized HP 4.0 installed. After building and installing from the square branch touch is now working (different I2C addresses used). |
@herodk what do you see, in this case, when you run: There's an issue between the Pi 4 and Pi 3B+ where some pin initialisation on boot causes the i2c address to change between one and the other. So far I've only seen:
This is partly why we have a Pi 3 and Pi 4 branch for the HyperPixel 4- these respective addresses seem to be stable. However - and this is something of a guess, since I don't know what's really at play here yet - It's possible that this same issue is somehow affecting you intermittently. Edit: @herodk oops just read your edit :D |
on a Pi4, with a failed touchscreen boot |
@neutralinsomniac |
yep. just posting what was requested by @Gadgetoid |
Ok so fixed on my side:
|
Is goodix.dtbo one of the files installed by the hyperpixel script? |
anyway, same issue even after disabling i2c in raspi-config. touchscreen fails to be found:
|
Try that: Power down the board, remove the screen, plug again and boot |
Tried it. No dice. I still think this is heat related, as myself and others have observed. |
Could you please give us : $ ls /dev/i2c* because seems i2c issue :S |
|
@neutralinsomniac |
TLDR: I have a software workaround prepared for this issueThis seems to work in my setup, but I'd appreciate any feedback. This splits the hyperpixel4.dtbo into 3 dtbo files, a "common" one containing the i2c, backlight and GPIO setup, and two for the different touch i2c addresses- one for To get it installed:
Hardware FixSince it's not a showstopper we'll fix this in hardware when/if we next respin HyperPixel4 (requires redesign, re-testing, new PCBs, new pasting templates, reconfigured pick-n-place etc). However, a super easy hardware fix is posted below for those who have resistors lying around and don't want to mess with software. (Though if this software transpires to work, I will roll it out as the standard setup for Pi4/HyperPixel4 users) Further to my earlier post I've - a couple of times - seen the same issue as @neutralinsomniac where the Pi 4 will start up with the touch on My hypothesis is that the How is HyperPixel4's touch set upSince the hardware i2c bus is taken by the vital V-Sync and H-Sync signals, HyperPixel4 uses a software i2c bus - the i2c-gpio module - on pins BCM 10 and BCM 11 (https://pinout.xyz/pinout/hyperpixel4) in order to communicate with the touch IC (and additionally anything connected to the breakout header). The The touch IC's interrupt line is additionally connected to BCM 27 and my theory is that this pin is doing something on startup that previously did not happen on the Pi 3B+ or other models of Pi. Update 1Right now if I reboot I'll get address 0x5d, but if I cold boot I'll get address 0x14. That seems much more logically consistent than it was for me before and could be related to the fan heater we've got blazing away to fight back the cold (and my butchered Pi 4 with no heat spreader to boot). I'll crack the window, let it cool quickly and see what happens. Update 2... I cooled it down. Rebooted. It works. Rebooted again... still works. Rebooted again... still works. I guess that's temperature sensitivity on the Pi 4 as good as confirmed? I've been talking to engineering and it transpires that there's a resistor/capacitor pair on the board that's responsible for resetting the touch/LCD. These would, of course, be somewhat temperature sensitive- but normally this effect would be negligible. It's clear that some twiddle on BCM 27, and the reset condition are happening so close together that the slightest change can tip the balance. Of course, this is what's implied by the term a "race condition." For me it seems to always work on a cold boot (as in shutdown/boot up, not temperature cold!), but rebooting causes it to drop back to the (correct) 0x5d address. Update 3... I warmed it up. Pointed a fan-heater directly at the HyperPixel4/Pi4. Rebooted again... now touch has failed. Now- to figure out how to fix this. The FixNote: I'm testing a software workaround that could replace this where smooshing in a resistor is inconvinient. It looks like this is a hardware issue with the interaction between HyperPixel 4/Pi 4 - an extremely intermittent, temperature-sensitive race-condition between the Touch Interrupt and Reset lines to be precise. I should have investigated this further when I first saw the This can be fixed with a future revision- but since this will require design tweaks, testing and retooling it's not going to be imminent. In the mean time my tests seem to suggest it's possible to fix this in the field with a single 1meg Ohm resistor in what must be the most simple and elegant in-the-field hardware bodge I've ever had to deploy. Observe the breakout garden header on the side of your HyperPixel 4- it has a 3.3v and an Int pin. The trick is to:
I'm sorry it's come to this. Alas this is one of those obtuse problems that's very difficult to catch in testing and the fix is simple and - for me at least - appears to be reliable. Appreciate any and all feedback on this since the temperatures involved in my test (fan heater vs open window on a cold November day) aren't exactly scientifically rigorous. And, again, sorry. It's taken me far too long to get my head 'round this issue, achknowledge the problem and come up with a fix. |
Fix confirmed. Just letting you know I had this exact issue - touch only working sometimes on a raspberry pi 4 running Octoprint Buster. Your patch git clone https://github.com/pimoroni/hyperpixel4 -b pi4-i2c-fix fixed my issue perfectly. Thank you for finding and fixing the problem. Like others above, the hyperpixel was showing up as a 0x5d on boot with no physical touch involved. |
If it helps, my pi is in an enclosure powering a Prusa MK3s, which can get very hot, although right now it's only reading 20C because I haven't started a print job yet. I was doing soft reboots as I tried to fix other issues. I control it via ssh, there's no physical keyboard or other monitor attached, and I have two USB devices attached to it: the Prusa MK3s and a Logitech C910. |
I cant speak for the pi 4, but on a 3b+ with the latest buster release, my touch coordinates were all over and needed manual adjustment to the values obtained from xinput-calibrator, but installing the alternate goodix driver from the Hyperpixel4Touchscreen repository gave perfect touch points, like perfect to the point of needing to delete 99-calibration.conf to not screw up what was already correct. |
Thanks - i've added the pull-up resistor. |
Just wanted to say I had this issue with a Raspberry Pi4 and a HyperPixel4 and couldn't for the life of me understand why on some reboots it was just failing but would work the next day. Had it constantly failing, found this, installed it, immediately worked on reboot. |
My touchscreen fails to init 9 times out of 10 on boot. diff between a bad boot and a successful boot below. Anecdotally, it seems to work more reliably after the pi has been turned off for a while, but I only have 2 successes to go by. Heat issue maybe? This is on a pi4.
The text was updated successfully, but these errors were encountered: