PI Zero W hangs when booting with USB keyboard

Patchbox is a great idea and could save a lot of hassle with using the PI’s for audio, but it hasn’t worked for me so far.

I’m using a PI zero W and when I have a USB keyboard plugged in (through a OTG adapter) the PI hangs and does not finish booting up. The power adapter should have enough power and I’ve tried two different USB keyboards.

I’ve also been unable to use SSH. I add the correctly configured wpa supplicant file and the ssh file to root, but the patchbox will not allow me to log in.

By default, Patchbox OS is configured to host an access point, it may be interfering with the wpa supplicant config, so you should first connect over WiFi and disable the hotspot.

Not sure what’s up with the USB OTG not working, the OS is running a ‘real-time’ config kernel which may have its own issues, we plan to include an updated kernel version in the OS upgrade to ‘buster’, so stay tuned. :slight_smile:

Bump. I’m experiencing the same issue with the new build but with a summertime build it boots and runs just fine. If I leave the OTG unplugged then everything is great, but as soon as I plug in the USB Keyboard via OTG it hangs.


Do you get any error messages printed on the display / ssh terminal? Is there any useful information in dmesg log or if the system crashes completely, you may check logs of previous boots.

Also you may try switching to regular Raspbian kernel:

sudo apt install raspberrypi-kernel
sudo reboot

Thanks for the super quick reply! This did solve the problem and I can boot and use the new patchbox with a raspberry pi zero w. With the RT kernel every time I plug in the OTG cable the OS hangs. When I look at kern.log I don’t see anything concerning, should I dump that log somewhere for info?

Does it contain information from previous boots, or only the current one? You may put the logs on pastebin.com and share the links here.

I have the same problem with a USB Keyboard on a rpi zero W. In addition I attempted to plug in a thumb drive and the system froze as well.

My image was built from the patchbox-2020-03 branch using using build-docker.sh

When I installed the raspberrypi-kernel and rebooted the issues went away.

Can someone tell me how to reinstall the original RT kernel so I can test and get logs for debugging?

sudo apt install raspberrypi-kernel-rt

If the kernel does fix the issue with this, you may submit an issue on the kernel repository here: https://github.com/raspberrypi/linux/tree/rpi-4.19.y-rt.

I performed 2 tests.

  1. I booted with a USB drive attached (boot failed).
  2. I booted and then attached the USB driver (locked up)

In both cases I removed the micro SD card and copied the logs. I then edited the logs to start with the boot sequences.

It seems to show a collision between the bluetooth and the USB. Do you want the logs?

I’d suggest creating an issue on the Raspberry Pi kernel’s GitHub, and mention that you’ve used the kernel from rpi-4.19.y-rt branch. However, keep in mind that this branch is supported by community effort and it’s not the officially supported one, so it may take a while before it gets resolved.

I found this on a page about using the Zero wit hthe preempt-RT kernel[1]

For the Zero, you also need the options:

    ~$ sudo nano /boot/cmdline.txt
    # Add the following options:
    dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0 dwc_otg.nak_holdoff=0

if you are using the USB port, otherwise the Raspberry Zero freezes immediately as soon as you connect something to the port (USB drive, Wi-Fi dongle etc.)

I have not had the chance to test it yet.

[1] https://lemariva.com/blog/2018/03/raspberry-pi-zero-w-preempt-rt-kernel-performance

1 Like

The change noted above is not a kernel edit, it is a simple edit of the /boot/cmdline.txt file to add the one line.

Give it a try and see if it works plz

makes no difference, I guess the zero w is not suited for patchbox os

I got the zero to work by replacing the realtime OS with the standard OS. The zero has a slightly different chip and that may be the source of the issue. I have not had time to go back and retry the realtime OS to see if I can find a way though.