Bug #75
closedUSB keyboard stops functioning after idle period
Added by Farb about 6 years ago. Updated about 5 years ago.
0%
Description
I have noticed in the last few core builds (up to and including v29) that if the USB keyboard is idle for too long, it stops working. Sometimes unplugging/replugging the USB connector fixes the problem and sometimes it doesn't.
Updated by foft about 6 years ago
Two potential problems:
1) max number of devices was decreased in v28, should have no impact but it was a change.
2) SIO can block usb polling and there have been significant sio changes.
This really seems to be elapsed time? Did you check another keyboard? Any particular software running?
Updated by Farb about 6 years ago
I have seen it happen a few times using the same USB keyboard (which was also the same keyboard I used on the MiST and don't recall having a problem):
1. Last night using v28 playing a trivia game ("Millionaire" from the 2018 ABBUC software contest). We contemplated an answer a bit too long and the keyboard would no longer work. I unplugged/plugged it back in but it did not recover. No disk activity (or any other activity) occurred in the time between it working and not. Was forced to reboot the EclaireXL and the keyboard started working again. The game's ATR file was loaded from the built-in disk emulation and wasn't using any external device. Two joysticks were plugged in but not being used.
2. It happened a number of times several weeks ago while working on Sdrive Max ATX code (don't know which core version but it was a few back -- maybe v25 or v26). I was running Diskey to load individual disk sectors and let things sit idle to the point that the attract mode color cycling had been running a while. When I resumed trying to load sectors, the keyboard wouldn't respond. I distinctly remember unplugging/plugging the USB connector and recovering at least once but can't say with certainty that it fixed it consistently. One joystick was likely plugged in at that time.
Could a problematic ribbon cable between the main and daughter boards be a possible cause? Could be irrelevant but I haven't replaced a faulty ribbon cable that caused joystick problems. I merely swapped the two cables and joysticks started working properly.
Updated by foft about 6 years ago
Unlikely to be the ribbon, though if its iffy you should replace it. I say that because while the joysticks are connected via the ribbon, the usb ports are directly connected to the fpga.
Might be worth trying a different keyboard to see if it still happens.
Do you know if the core is still running? i.e. do the joysticks still work + the screen is still update + music playing?
Updated by sadosp about 6 years ago
Farb wrote:
Could be irrelevant but I haven't replaced a faulty ribbon cable that caused joystick problems. I merely swapped the two cables and joysticks started working properly.
Irrespective of the problem with the keyboard,I am very surprised, why you haven't change the ribbon cables till now with the new ones I sent you!
Updated by sadosp about 6 years ago
sadosp wrote:
Farb wrote:
Could be irrelevant but I haven't replaced a faulty ribbon cable that caused joystick problems. I merely swapped the two cables and joysticks started working properly.Irrespective of the problem with the keyboard, I am very surprised, why you haven't change the ribbon cables till now with the new ones I sent you!
Updated by Farb about 6 years ago
Yes, the core is still running because we were hearing music play. The game we were playing didn't use a joystick so we couldn't test that. I can try to reproduce with something that uses both joystick and keyboard. I will also see if I can reproduce with my other USB keyboard.
@sadosp: I know, I was being distracted with other things and kept putting it off. The new cables are sitting right here waiting to be replaced. I will do that today :-P
Updated by foft about 6 years ago
Well I just received Millionaire on disk so I can give it a go and see if I have the same issue. My keyboard definitely keeps working when idle in basic since I leave it there all the time while debugging the core:-)
Updated by Farb about 6 years ago
Frustratingly, I have not been easily able to reproduce the effect with the keyboard it occurred on before. I will spend some more time attempting to reproduce soon but will be traveling for the next week or so.
Updated by foft about 5 years ago
Jurgen has this with both his keyboards after about 20 minutes.
I also thought I saw it when running the Eclaire for a prolonged period at a show earlier this year.
Anyway did some investigation...
I left my keyboard for an hour and it froze. I think its only when its idle, so pressing a key makes it take longer.
Updated by foft about 5 years ago
So, decided to take it seriously.
My picoscope claimes to decode USB, tried that and found it pretty poor.
So I tried to capture the full data stream to PC and decode it with sigrok. I got some valid packets once or twice, but it seems unreliable, I think on the capture side. These data rates are pushing streaming on the picoscope.
Updated by foft about 5 years ago
Tempted to get a Saleae logic USB3 analyzer to capture at a higher rate and they also have USB decoding. Its several hundred though, so not sure. Clearly its worth it if I'd use it a log but not sure I will. They very kindly have electronics enthusiast pricing (not commercial) which makes it more likely.
Updated by foft about 5 years ago
While I mull that I tried building a core that can enter the menu with fire. So I can see if it is indeed USB that crashes and not the whole ZPU.
Updated by foft about 5 years ago
I left it for an hour, then typed and it worked... sigh.
Updated by foft about 5 years ago
OK, finally froze. I could still enter the menu with fire and it worked. So ZPU is alive, just USB is dead.
Ordered the Saleae analyzer to see if the USB debugging is any good too:-)
Updated by foft about 5 years ago
Trying it with two keyboards. So far an hour and working.
Though I have a hunch that it'll stop working in 10 minutes!!
The code does this:
if(timer_get_msec() > host->poll) {
host->poll = timer_get_msec()+1;
I reckon it overflows after about 70 minutes.
Updated by foft about 5 years ago
((2^32)/1e6)/60 = 71...
So trivial fix. I clearly don't need the Saleae to debug this one, but that isn't so bad. I can use it for the real-time bus capture to debug the whole system and also for the usb hub debugging.
Updated by foft about 5 years ago
- Status changed from In Progress to Resolved
Added a timer elapsed function that handles the overflow. This makes the max delay 35 mins, but I think that is ok... This is usually used for ms or us delays.