Keybow needs to be rebooted after detach/attach
andrewcarson opened this issue · comments
I am using the Keybow attached to a powered USB hub.
When I detach and then reattach the hub from the computer (Windows 10), the Keybow does not re-register. I need to detach and reattach the Keybow itself (i.e. reboot it).
This is with the pre-built image from the sdcard folder
If I install Raspian (Buster) on the Keybow, then clone, build and run the keybow binary directly, the detach/reattach via the hub works as expected.
This suggests (to me) that there is something missing from the cut-down Linux.
I believe I'm having a similar issue.
This works fine if I power Keybow directly, so it must be some interaction between Keybow -> Hub -> Host. Possibly blipping the power supply enough to crash the Pi, but not reboot?
I'll go on the hunt for a powered hub (there must be a loose PiHub somewhere) and see if I can replicate.
Tested with an ORICO HF9US and it works fine if I disconnect/reconnect the hub from the host PC.
I'm afraid this is more likely to be an unavoidable electrical issue- IE: disconnecting/reconnecting your hubs, despite them being powered, causes a blip on the voltage supply that's enough to destabalise but not reboot the Pi. It might be worth connecting an HDMI cable & monitor (if possible) and seeing if you get any system output during the disconnect/reconnect.
Another potential test would be to connect an external power supply and repeat the experiment- connect a good 5v microUSB supply to your keybow, then disconnect/reconnect your hub.
Most peripherals don't have an embedded Linux system running on them, so we're probably susceptible to power instabilities that don't affect keyboards/mice or simpler things.
This also occurs for me on both a powered USB socket and a USB port on the back of my monitor. I thought I'd solved it by moving it to the monitor slot and it was fine for a couple of days, but now it's started needing a reboot every time I power up my computer and because the USB cable is in the back of the monitor, I need to yank the micro-USB end, which seems fragile.
This would be expected as it loses data to the computer, thus needing to power off and on the PI. What I did to avoid needing to plug and unplug the USB cable is to by a Powered USB HUB with independent power switch to each port. (https://www.amazon.com/gp/product/B083XTKV8V/)
Surely that's the same as having it in a powered USB socket on my laptop? That solution didn't work for me.
Perhaps I didn't explain my self correctly. You want the Pi to cycle power other wise it won't load when restarting the computer. My workaround was using the Hub to hit the power off and on after restarting my computer.
I'm going to try bumping the kernel version & software for the keybow firmware at some point.
If that fails to get the thing more tolerant of disconnects, perhaps it's worth exposing a "reboot" feature where holding down a button for long enough (assuming the whole software stack hasn't crashed and burned) will force reboot the system or reset the USB or something.
I think this is a solvable problem, but I'm stretched so thin right now you could tie string around my ankles and fly me.
Hey fair enough, If there anything I can do to help let me know. testing etc.
I'm not holding out hope that it will make any difference, but updating the kernel/system and adding in WiFi connectivity will at least make it possible to debug (in cases where a Zero W is used anyway) and find some kind of solution.
My biggest issue at the moment (aside from lack of time... it's 11:30 pm here right now!) is being unable to replicate the keybow USB hub problem. It probably doesn't help that I don't have or use a regular USB hub!
While I'm futzing about with stuff, you could try - https://gist.github.com/Gadgetoid/f2ff7f3854a7a102074e8daf458063f5
I don't recall if this build actually works at all - it's just taken me 2+ hours to replicate it since I had lost my updated kernel config.
Note: if this is an electrical issue with an unstable voltage or drop in voltage when disconnecting a USB hub.. then that could mean the Pi has frozen/kernel paniced and is not possible to recover without a power cycle. Difficult to tell without a connected display, or debug over WiFi. That said, it strikes me that if panics/freezes are an issue there might be some watchdog functionality we can use to reset the Pi if it gets in a bad state.
@ everyone - do your light patterns - if you have any continuously running - still work when the keybow doesn't?
Edit: Just updated keybow-wifi.zip on the linked gist with a fresh kernel/initrd and the new key mapping stuff from this repo.
@Gadgetoid All good, I'm willing to test it and see what I find. I got it loaded and ssh'ed in going to do some testing.
okay so I was unable to repro the issue. (that was with vanilla files. I did not make any changes).
I'm going to load my prior backup of my SD and confirm I can still repro it with all my mapping. Going to test a few things.
I monitored dmesg via ssh.
[Nov 4 18:56] dwc2 20980000.usb: new device is high-speed
[ +0.035554] dwc2 20980000.usb: new address 12
[ +0.021971] configfs-gadget gadget: high-speed config #1: config
[ +0.006186] gs_console_connect: port num [0] is not support console
Okay, so after some testing. The issue is with v0.0.4 only. With the build you provided I can't repro the issue.
Okay, so after some testing. The issue is with v0.0.4 only. With the build you provided I can't repro the issue.
That is very interesting! Looks like I need to check in my kernel configs, do a release with all the updates (and bonus WiFi for people brave enough to use it) and cross my fingers!
My intent with WiFi support was to bring luasockets into Keybow so you could send data from the keybow to a server, or vice versa. I didn't do all that much testing, though, and it remains to see how robust it will be. I'll probably shelve Luasockets until the updated kernel/initrd has bedded in and been tested for a while. One step at a time.
Good news if the new firmware both works and doesn't hang/crash. Thank you very much for testing this!
👍🏼 No problem, I'm no expert but just comparing. Notice that you have included new Device Tree Blob/overlays compared to v0.0.4. In the build you provided it has bcm2708 and bcm2835 Device Tree Blob/overlays for both rpi-zreo and rpi-zero-w. ?? I wonder if that has anything to do with? In v0.0.4 it does not have the DTB for bcm2835..
I my self am using a Pi Zero W v1.1
root@keybow:~# cat /proc/cpuinfo
processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7
Hardware : BCM2835
Revision : 9000c1
Serial : 00000000bbf2c0e9
Model : Raspberry Pi Zero W Rev 1.1