I have a two-player arcade build using a Picade X USB-C HAT for player 1, and a Player X board connected via usb for player 2. I’m also using Plasma buttons for both players (I modified the plasma daemon to support running multiple daemons, see plasma/daemon/usr/bin at multi-daemon · PinkFreud/plasma · GitHub ).
Somewhere along the line, the controls and plasma backlights stopped working for the controls connected to Player X, but only at boot. It’s easily worked around by unplugging the usb cable from the Pi and plugging it back in, and restarting the plasma service for the Player X. While the workaround may be easy, it’s far from ideal!
When this issue first appeared, I realized I was using one of my first RPi4s, with an OS image that had been used for a number of projects prior to being set up as an arcade machine, so I decided to build a fresh minimal image with Raspberry Pi OS lite + Retropie. Unfortunately, this issue continues to plague my build even with the new image. It looks like something is interfering with the Player X on boot, but I can’t figure out what.
What makes this even more maddening is that the Player X’s button backlights cycle on boot when the usb ports first get power, so I know they’re working. Likewise, the controls connected to the Picade X HAT work on boot, and the plasma backlights come up without issue.
It looks like firmware updates for the Pi 4 broke the Player X at boot.
If I roll back to /lib/firmware/raspberrypi/bootloader/default/pieeprom-2020-04-16.bin, Player X springs to life at boot. However, this original fw release had poor power management, and caused the Pi 4 to run quite warm. It also lacks the ability to power the Pi on via gpio pins, which is absolutely necessary for my build. /lib/firmware/raspberrypi/bootloader/default/pieeprom-2020-09-03.bin, and all stable releases since then, provide much better power management, the ability to power on via gpio… and break the Player X board on boot, requiring I unplug and reconnect the usb cable to bring it to life.
What GPIO pin are you using to turn the Pi on? I ask because grounding GPIO 3 has worked for me, for what seems like ages. It works on my Pi Zero’s,3A+'s, 3B’s, and 4B’s.
That being said, I don’t think that’s how the Picade hat turns on the Pi. I could be wrong but doesn’t it totally remove the power after it shuts down. Then just power it back up when you push the button? Just looking for a little more info is all.
RPi 4 : Lost GPIO-3 restart (and fix) - Raspberry Pi Forums - Power on via gpio 3 wasn’t enabled in the original Pi 4 fw release. However, I was mistaken about the date - 2020-04-26 appears to have WAKE_ON_GPIO=1, though I’d have to test the power switch w/ that firmware to be certain.
I’m not powering the Pi via the HAT - I’ve modified an existing cabinet (Arcade1Up), and connected it’s power switch to gpio 3 on the Pi directly.
Ok, thanks for that link. Reading it has jogged my memory somewhat. I (now) do remember there being a difference in the shutdown state when the Pi 4 was “first” released. And a change being made to bring it inline with other Pi’s like the 3B.
I can remember flashing the eeprom on mine now that you mention it. Getting old sucks as they say. My pain meds don’t help either with brain function. Some days are worse than others.
Anyway, I can see where that would be a problem. I have several Pi’s setup headless where I use grounding GPIO 3 to boot them up. Having to unplug and replug the power supply can be a PITA.
EDIT: I actually posted in that thread. I use the same username there that I do here, alphanumeric.
@alphanumeric: No worries. We’re all getting old, and on top of that, 2020 had to have been at least a decade long. ;)
And yeah, what sucks the most here is that, if power on via gpio doesn’t work in 2020-04-26 (I’ll need to go back to test that!), I’m stuck either reconnecting the Pi’s power cable to boot, or reconnecting the Player X’s usb cable to get it to work after boot, depending on whether I’m running 2020-04-26 or 2020-09-03 (or later). At least I know the problem stems from a change in the firmware - the question is, is this something Pimoroni can resolve on their own, or do we need to go to the Foundation to ask them to change something in the firmware?
That I don’t know? I think the switch to Pulse Audio has caught a few retailers out. Pimoroni being one of them. It’s messed up a bunch of there how to tutorials.
On a semi related note, I can relate to your frustration. On my Pi400 I have to press Fn F10 “twice” to do a shutdown. It’s only a select few of use with this issue. The Pi Foundation is aware of it, can reproduce it, but don’t have a fix. =(
The Pi Foundation is aware of it, can reproduce it, but don’t have a fix.
Yeah, that’s where I’m at w/ Pimoroni support (I emailed them about this issue when there wasn’t any movement on this post). They’ve confirmed it happens with some Pis, but no idea about a fix yet. Now that I’ve identified the root cause, I wanted to update this post - I do NOT want to be that person who says ‘it’s fixed now!’ and goes away without an explanation. :P
And I applaud you for that. Way too often on numerous forums a thread gets tagged as solved, with a “fixed it” last post. But no info on how it was fixed?
1 Like
I have several headless setups that once I have them all setup and running, I never update / upgrade. They work just fine so why temp fate. Pi’s that I use as desktops etc I do update / upgrade. Then backtrack if it breaks something. Most of my headless setups don’t need Internet access. My one exception is my Pirate Radio that plays my Classic Rock Internet stream. I still don’t update it, no real need IMHO. It works with no skips or pauses in what its playing.
I’ve long been involved with system administration / engineering, given that I’ve been working in that field for about two decades now (damnit, I am old!). I’m wary of not updating, mostly because it means skipping security updates.
But that’s just me. ;)
That’s why I update my Pi400 that is exposed to and frequently on the Internet. Most of my headless setups have no Internet access. They don’t need it for what they do so I disable WIFI. I have a bunch of Pi’s running older version of PiOS. I don’t update them to the latest version until they fail to boot up and I have to start over from scratch.
One last update here - I found that there are several stable releases between 2020-04-16 and 2020-09-03. The last release the Player X works on at boot is 2020-07-16 - the next update, 2020-07-31, breaks it.
2020-07-31 Standardize USB port power control across board revisions - BETA
Turn off USB port power for 1-second regardless of boot-mode. This appears to resolve an issue on R1.3 and older board revisions where some USB devices would fail upon reboot. On R1.4 USB port power is turned off automatically by the PMIC so this is just held in reset for longer. For earlier board revisions the USB port power is explicitly turned off via XHCI. This can be overridden via USB_MSD_PWR_OFF_TIME in the EEPROM config.
Update to the latest Broadcom memsys FW - no significant functional change.
Crap. That looks like it may be the issue that’s plaguing the Player X - except that it fails when usb power is interrupted at boot.
https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/release-notes.md
USB_MSD_PWR_OFF_TIME
During USB mass storage boot, power to the USB ports is switched off for a short time to ensure the correct operation of USB mass storage devices. Most devices work correctly using the default setting: change this only if you have problems booting from a particular device. Setting USB_MSD_PWR_OFF_TIME=0 will prevent power to the USB ports being switched off during USB mass storage boot.
Minimum: 250
Maximum: 5000
Default: 1000 (1 second)
Setting USB_MSD_PWR_OFF_TIME=0 doesn’t appear to fix the issue with fw 2020-07-31 and newer, though the docs indicate that this option may only be in use when booting from usb mass storage. So far, the only fix I have is to go back to 2020-07-16 or earlier fw.
I may wind up reporting this issue to the RPi Foundation this weekend, as it seems that this should be able to be disabled for devices which don’t play nicely, even when not booting from USB MSD.
I know I’m a day late and a dollar short here, but this seems to still happening and I’m looking into it.
I have managed to reproduce the failure on reboot with a Raspberry Pi 4 and am in the process of trying to figure out if I can fix this in software to make it more resilient.
I was working on the assumption that it was the lack of interrupting the port power that caused the issue. But now I’m trending toward the power interruption being the problem. It could just be that the Player X starts streaming out events as soon as it’s powered on, which ends badly if a connection to the host isn’t ready.
This might explain why some users have had similar issues with Windows PCs, but I was unable to replicate with mine.
Not sure if it’s related, but here goes. I have a PICO RGB keypad running Circuit Python. It’s setup as a USB HID device. It would more often than not, not work when I booted up my Windows PC. Unplugging and plugging it back in would get it going, until I rebooted etc.
Putting a 30 second time delay before my code runs solved that issue. It was getting power, but the PC / Windows wasn’t ready to talk to it.
I’ve created an updated firmware which you can find here: Picade-Player-X-2019-04-29.bin · GitHub