Keyboard keypress repeat and keyboard stop working on Raspberry Pi

Whoa! Recursion!

Deja Vu!!

I thought it was a keyboard repeat with a long delay.

I haven’t noticed a problem with this for a good while, using a cheap USB out plug and type A to mini lead, then mini USB to micro adaptor. Even using an unpowered 4 port USB hub to add a memory card or two.
However, I have recently modded my RPi. Basically added internal 16Gb USB drive, (this has thrown up another issue I’ll raise in another topic,) two extra USB ports, PCF8583 I2C realtime clock with battery backup, (still to get working!) and a Nokia 5110 display. Now powered from a 4 way 5.1A USB supply, (MAPLIN, 2.1A on first socket and 1A on the rest, although on inspection, all four are in parallel!) Using a USBA to USBB cable, added USBB socket on RPi to feed four port hub and also RPi via polyfuse.
Anyway, following investigation, supply at source is 5.15v.I’m dropping .5v on the lead and another .25v+ on the RPi side of the polyfuse. Temporary fix is to use the old USBA to micro USB lead from the same supply as well.
The point I’m trying to make is, the lead from the supply can be as critical as the supply itself and may be a factor in the key-repeat thingy.
Although I’ve managed to type all the above on this setup without the second lead and no problem!
28th March 2014 ROM used with, and now without problem!

I have recently modded my RPi. Basically added… PCF8583 I2C realtime clock with battery backup, (still to get working!)

The Pi Kernel and RTC module only support the DS1307 RTC and compatible chips, like the DS1338 we use in our Pi RTC.

The PCF8583 was used in Archimedes, A3000, A5000 & RiscPC. So it could be made to work but would require modifying the kernel & RTC module.

Are you still planning on looking at this, Jon? I’ve got a free block of time coming up shortly so should be able to look at it myself.

Here’s one for you to ponder.

From time to time I get the keeeeeeeeeeyboard repeat problem. Standard generic keyboard.

But – I have written a demo of my OLED driver that uses OS_Confirm to wait for me (because it gives an easy choice of mouse click or keypress). And what happened on a couple of occasions? Yup – you guessed it. Pressing SELECT to act as a ‘y’ keypress causes everything to go flashing by as I clicked once and the computer obviously saw “yyyyyyyyyyyyy”.

You can now wipe up that coffee you just spat across the desk…
…cos…
…yeah…
…I thought the same thing.

[note: (older) self-built ROM with sources from mid-January (’cos unpacking them TakesAges so I only do it every-so-often)]

Pressing SELECT to act as a ‘y’ keypress causes everything to go flashing by as I clicked once and the computer obviously saw “yyyyyyyyyyyyy”.

Always labelled as “key bounce” issues. Of course you could have bounce on the mouse events.

Having said that I had key repetition and mouse event repetition issues on this machine back then (last year – New Year) but not on current releases. Bear in mind that this machine is actually a W7 laptop running RPCEmu.

I initially thought it was a mouse button problem.

I thought we were only supposed to have bounce in the mosh pit?

Okay, okay, I’m getting my coat…

For who ever looks at this: the Foundations latest USB is discussed at http://www.raspberrypi.org/forums/viewtopic.php?f=28&t=70437

Are you still planning on looking at this, Jon?

I won’t be doing anything for the forceable future. All development is on hold whilst I help a company out, unfortunately it involves lots of travel, so I’m not going to have any free time.

For who ever looks at this: the Foundations latest USB is discussed at http://www.raspberrypi.org/forums/viewtopic.php?f=28&t=70437

Interesting; I didn’t know they were still making significant changes to the driver. But since that new version is still in development, I think I’ll play it safe and go with the original FIQ fix, at least for now.

I won’t be doing anything for the forceable future. All development is on hold whilst I help a company out, unfortunately it involves lots of travel, so I’m not going to have any free time.

Hope you’re still going to make it to ROUGOL later today? We need you there!

We need you there!

I know, I’m trying to figure that one out at the minute, couldn’t have come at a worse time!

Puzzled. I had similar – possibly the same – symptoms, but the (apparent) cure was surprisingly easy. Has anyone said this before? I’ve not read the whole thread terribly carefully…

The problem didn’t appear until the Pi had been on for quite a while, and at first was just the occasional failure to register a key release or a mouse button release. Then it gradually got worse until the machine was unusable. Ctrl-break – still the same problem. Switch off, wait ten seconds for the caps in the PSUs to drain, switch on – still the same. Disconnect the PSUs, reconnect, still the same. Leave the whole lot off for a couple of hours and restart: all hunky-dory for several hours again.

Thinks: sounds like a supply voltage issue, warm PSUs or warm cables or connections dropping a few tenths of a volt? Try reducing the load on the USB hub, disconnecting the hard drive and a USB stick. Still the same. Try moving the keyboard to the second Pi USB connector, leaving everything else on the hub – problem appears to be solved – been running continuously now for two days and all’s well. Not only is the keyboard behaving, so’s the mouse. Both cheapies from Wilkinson’s.

The hub is a Pi Hut one, supposed to stop the hub power feeding back to the Pi.

Progress update: I’ve successfully merged in the latest driver from the Linux sources (and put it into CVS last weekend), and have moved on to trying to get the FIQ code working. It looks like there are two tasks which the FIQ handler can be used for – processing SOF interrupts and processing split transactions.

Split transactions look to be a bit tricky, as the current implementation appears to assume that the FIQ handler is permanently installed, which is something we can’t guarantee under RISC OS at the moment (e.g. the kernel will temporarily reclaim the vector when doing some memory remapping operations, and technically any other program could come along and claim the vector for its own use). So for the moment I’m currently ignoring the split transaction code and focusing on SOF handling.

The SOF handler is a lot simpler and was pretty straightforward to get working, including falling back to full IRQ mode when the FIQ vector gets reclaimed. However there is one major bug I’m seeing, which is that after a random amount of time VCHIQ will completely die. Sound stops, pointer movement stops, and if you do something which will cause the OS to block waiting for VCHIQ (e.g. mode change) then the whole OS will come to a halt. I’ve got a checklist of things to work through to try and narrow down the cause, hopefully that will result in something useful before I have to start poking around adding debug code (and I have a feeling this is going to be one of those horrible bugs that will vanish when debugging is enabled – I certainly don’t remember seeing it when I was running a debug version of the modules)

I think I’ve fixed the problem that was causing VCHIQ to randomly die – it looks like it was some quirk of the MPHI peripheral that the FIQ code was using to trigger IRQs. So after a bit more testing and tweaking I think I should be able to check in the first part of the FIQ fix (moving the SOF handling over to using FIQs).

Today’s ROM contains the first part of the FIQ fix, where the SOF interrupt is now handled by a FIQ handler. I still need to get the second part of the fix (split transaction handling) implemented, but hopefully this first part is enough for people to start seeing improvements.

So let me know if you see anything different with today’s ROM – either good or bad!

Tried this on my Pi with latest HardDisc4 as well and with wired Keyboard and mouse, no issues but if I try my Microsoft Wireless Keyboard 800/Mouse 1000 combo which used to cause issues the keyboard seems to work OK (i.e. I can F12 and type commands but if I move the mouse at anytime from when the hourglass appears on the BootFX screen it moves about and inch and then total lock-up.

I’ll have another jiggle with it over the weekend but is there anything I can do to get some more meaningfull debug when it happens if that helps?

Actually, I’ll go and try it with the latest Raspbian image as well to make sure it’s OK with that too before futher furtling but I’m fairly sure that was OK when I checked it post FIQ stuff on the Linux side.

Edit: Yes – it’s still fine under latest updated Raspbian image.

if I try my Microsoft Wireless Keyboard 800/Mouse 1000 combo which used to cause issues the keyboard seems to work OK (i.e. I can F12 and type commands but if I move the mouse at anytime from when the hourglass appears on the BootFX screen it moves about and inch and then total lock-up.

So is that better or worse than it was before? :-)

I’ll have another jiggle with it over the weekend but is there anything I can do to get some more meaningfull debug when it happens if that helps?

Do you have a serial cable you can use to hook the Pi up to another machine? If so I can upload a build which has some debug code enabled which should be able to log something useful via the serial port.

So is that better or worse than it was before? :-)

Sorry, was not being even remotely coherent: Keyboard now better as in no dropped keypresses or repeats – tested this at the * prompt and in StrongEd and it kept up with my atrocious typing so that’s good – restored an older 5.21 ROM and it was back to dropping the occasional character and a few repeats.

However, the moving the mouse under both ROM’s was pretty much instant lock-up, although a few times I got a dialogue box saying that a Filer action could not complete or an Abort but then it was seized so it seems to be happy with the keyboard but never the mouse – either this kind of worked in a much earlier 5.19 ROM or I’m plain wrong about it working.

Idiocy not withstanding it’s still interesting that a mouse can brick it so substantially.

Do you have a serial cable you can use to hook the Pi up to another machine? If so I can upload a build which has some debug code enabled which should be able to log something useful via the serial port.

Many serial bits and cables I have but according to this I’d need something a but more substantial to drive the RS-232 from the GPIO – I’ll pick one up if that’s what’s needed but it’d have to wait until after pay day…

Before trying the new build, we went to test this with two keyboards that in the past tended to autorepeat using a 23.12.2013 build and low and behold we’ve not seen any miss auto repeats! We’ll try the new build and see if anything changes.

Last week I got myself a little dual-output USB power plug that claims to provide up to 2A. My eeePC is running the HMDI adaptor. The new power plug is running the Pi and the WiFi adaptor.

The Pi appears to function much as it has before. A few sticky keys, but less than before. Hasn’t trashed its SD image, but writing this I’ve probably just jinxed it!

The WiFi adaptor, on the other hand, has been the real star. It would often drop out, fail to see a WiFi signal, or just plain crash. Running on the new adaptor, I have listened to JPopSuki (Momori server, 192kbps) for over five hours and according to *EJInfo, have sent out nearly 12MB and received back half a gigabyte. Not a single interruption.

:-)

All I need now is a way to get DigitalCD’s streaming audio player to be able to record (save to MP3 files on disc).

Today’s build has the second part of the FIQ fix (split transaction handling) enabled. Let me know if this makes things any better or worse for anyone.

Seems to be fine with my keyboard and wired mouse, although I have noticed that if I draq a window the pointer seems to move about in a kind of parallax like there’s an offset wrong – I went back to a previous image from the 5th and it was doing it there too so maybe it’s something else – I’ll see if I have a previous image lurking on a backup/re-flash with RC12 and see if it’s just me.

RPCemu was fine with the image in that regard, and I tried it on a another Pi as I have a revision 2 one now too.

Anyway – back to the mouse move crash thing – it still bricks if I try the wireless mouse :(

Do you have a serial cable you can use to hook the Pi up to another machine? If so I can upload a build which has some debug code enabled which should be able to log something useful via the serial port.

Many serial bits and cables I have but according to this I’d need something a but more substantial to drive the RS-232 from the GPIO – I’ll pick one up if that’s what’s needed but it’d have to wait until after pay day…

I have one now (it took a while to ship form Shanghai) and can see boot info as the Pi boots in a puTTY window so if I can turn on some kind of debug I can wiggle away and send over the output if that helps.

No more problem here on a PandaBoard.
I can boot without a keyboard and the system does not crash every 3 days.