No keys register after a recent update of the firmware

Yeah, I’m pretty sure it’s an issue with one of the plugins I updated. Am thinking of setting all of them back to where they were the last time I flashed, and hoping that resolves it. I’ll update layer with which plugins I’m using - let’s see if we can help each other out.

Edited:
My previously working sketch is using these plugins:

  • BootGreetingEffect
  • TestMode
  • LEDControl
  • LEDRainbowEffect
  • LEDRainbowWaveEffect
  • LEDBreatheEffect
  • StalkerEffect
  • NumLock
  • Macros
  • OneShot
  • EscapeOneShot
  • MouseKeys
  • ActiveModColorEffect

I tried moving some stuff around last night, but now my PC is getting anything from the keyboard, tho I can see from the mod color plugin that it’s registering key presses. I had tried to update the various plugins, which was probably a mistake.

That could also be a cable problem. The keyboard reacts to keypresses if it’s getting power from the computer, even if no data is passing between them. I’ve seen this behavior several times, and it was fixed by unplugging/replugging the cable from the keyboard.

I’ve been unplugging and re-plugging in order to flash, since I’m needing to use the trick of holding down prog while I plug in the cable. I can try another cable, though.

Swapped cables, no difference.

1 Like

Manually uploading using avrdude worked. After I flashed it manually, the kbd switched from COM7 to COM9, and I was subsequently able to flash it from the arduino IDE.

NB - I really do mean the keyboard - the bootloader was on COM8.

I have exactly the same issue, happened to me 5 days ago after a ‘git pull’. Haven’t been able to flash something usable ever since, had to use an older keyboard :frowning:
If you find which plugin is responsible, I’d love to know what is causing this.

I’m still not finished with my pinpointing the source of the problem, but I suspect it is not related to a plugin.

This is what I have found out so far.

  • Flashing the default sketch with the latest (git-pulled) Kaleidoscope version works fine. So if it is a plugin problem, we can consider the ones in the default sketch to be ok.
  • The reason I believe it’s not related to a plugin is because I’ve commented out the entire Kaleidoscope.use() method, which contains the plugins to be used, but the problem still remains. I’m not entirely sure about this yet.
2 Likes

Someone with the right forum admin bits should probably move the discussion of problems flashing firmware from Windows into a separate topic.

3 Likes

Exactly this happend to me as well.

When you say “a git pull on Kaleidoscope”, can you be more specific? I’m thinking this may be a version mismatch involving the recent HIDAdaptor changes, which, if I recall correctly, require updated versions of KeyboardioHID, Kaleidoscope-Hardware-Model01, and the new Kaleidoscope-HIDAdaptor-KeyboardioHID module.

I can’t check right now, but the safest thing to do is to checkout everything at once via Arduino-Boards. Updating just one of the submodules (e.g. Kaleidoscope) by itself doesn’t always work.

I brought my keyboard back home to try to solve the issue. My home computer runs Windows 10, I had no problem, the keyboard was working OK.
This morning, I brought it back at work, computer running Windows 7, no keys register.
So this is maybe a driver issue, maybe the update of Kaleidoscope changed how the keyboard is detected on the OS side.

@merlin : the git command I used is one you taught me :slight_smile:

cd code/Arduino/hardware/keyboardio/avr/
git pull
git submodule update --remote --init
2 Likes

I used the same git command, fwiw.

This morning, I try again my keyboard at work, and it’s working fine. No more hanging, keys register well. I can’t explain why, the firmware is the same.
I’ll see what happens the next time I update the firmware.

I may have found the culprit, not sure. I wanted the latest Kaleidoscope version, so I updated my Arduino keyboardio package manually. I replaced my custom firmware.ino file with the default one, since my custom one didn’t work, as expected.

I proceeded to copy my custom code from my old ino file to the new ino file. Chunk by chunk, uploading and checking if it still worked. I also kept the new code for the HostPowerManagement plugin.

Well, it works.

The only difference between my old ino file and the new one I noticed is this line:

whereas it used to be const Key keymaps[][ROWS][COLS] PROGMEM = {. It may or may not be the reason why it didn’t work before. I replaced it with the new macro right away, so I don’t know.

Maybe @merlin can tell us, since he introduced that KEYMAP macro :wink:

So, when you build your firmware with the KEYMAPS() macro, you end up with a keyboard that doesn’t work, but if you define the keymap the old way, it does work?

It’s a false alarm, I was wrong about the KEYMAPS macro. My sketch works with both KEYMAPS and the PROGMEM declaration.

I still don’t know what is causing it. My somewhat big sketch works flawlessly.

However, if I compile and upload smaller sketches, like the LEADER example (https://github.com/keyboardio/Kaleidoscope-Leader/blob/master/examples/Leader/Leader.ino), it breaks.

If I slim down my sketch to the bare necesseties, it breaks.

I’m using the latest Kaleidoscope libraries.

Alright, I finally found the source of the problem.

This on Windows 7 64bit:

If the plugin “Kaleidoscope-HostPowerManagement” is not used and the method HostPowerManagement.enableWakeup() is
not called in the setup() function, the keyboard bugs out: the system hangs for about five seconds, and the keyboard becomes useless.

I tested that with my sketch, and the LEADER plugin example sketch I linked above.

Wow, this is interesting. That plugin, and that line, should not have such an effect. Thanks for tracking it down to it!

It would be nice if @kajsa.anderson or @Otso or anyone else with Windows 7 could confirm this.

Just saw this - when you say

I’m using the latest Kaleidoscope libraries

can you be more specific, in terms of git tags or hashes?

I’m on commit aa345fa618d0324d30cb71253a1a812c9d4be696 (link)

There’s been more updates recently (the new plugin system), but I haven’t tried those.