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’s interesting. I remember you use Windows 7? So do I. A week or so ago, I did a git pull on Koleidoscope and the keys stopped working/sending. When the firmware upload finished, the entire system hung for about 5 seconds. Then, nothing. The LEDs work, and so does the shortcut to disable them. I tried uploading the default sketch and it worked perfectly fine. I wanted to test this on my other computer but didnt get the chance yet. I had to revert back to version 1.22.0 for now, which I downloaded in Arduino’s Board Manager.
Edit: I think maybe a plugin in my sketch or a setting or something breaks with the update I pulled. I need to comment stuff out one by one to pinpoint the problem.
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 
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 
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 
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.