Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Plaid keyboard freezing after a few minutes #11667

Open
3 tasks
chrismetcalf opened this issue Jan 22, 2021 · 16 comments
Open
3 tasks

[Bug] Plaid keyboard freezing after a few minutes #11667

chrismetcalf opened this issue Jan 22, 2021 · 16 comments

Comments

@chrismetcalf
Copy link

chrismetcalf commented Jan 22, 2021

I recently re-flashed my Plaid keyboard using the latest version of QMK, and now after a few minutes the keyboard locks up and the USB device disappears from MacOSX.

Describe the Bug

I recently decided to upgrade my firmware on my Plaid keyboard to the latest version of QMK because I was having occasional issues with it freezing upon wakeup. However, now it freezes within a few minutes of being first plugged in, even if the keyboard is never actually used.

When it freezes, the USB device disappears from the MacOS USB listing and the status LEDs on the keyboard are frozen in their final state. No keystrokes are registered, and the debugger disconnects.

Things I've tried:

  • Replacing the mini-USB cable
  • Reverting to the default keymap
  • Rebooting...
  • Turning on debug mode and watching the output in QMK Toolkit. When the keyboard freezes, no error messages are output in the debug console, it just disconnects

The symptoms are very similar to what I had before at wake-up, and everything works again after I unplug and re-plug.

On the latest QMK I also notice that sometimes the key repeat seems to momentarily lose its mind, especially with keys like delete, and it'll delete half the line before I can hit another keystroke and cure it. This didn't happen before.

System Information

  • Keyboard: Plaid through-hole
  • Operating system: MacOSX 10.15.6
  • AVR GCC version: 8.4.0 from Homebrew
  • ARM GCC version: 8.3.1 20190703 gcc-8-branch revision 273027
  • QMK Firmware version: 0.11.53
  • Any keyboard related software installed?
    • AutoHotKey
    • Karabiner, but it is disabled for this keyboard. I only use it for the system keyboard.
    • Other: KeyboardMaestro
@spidey3
Copy link
Contributor

spidey3 commented Jan 23, 2021

Have you tried shutting down Karabiner and KeyboardMaestro completely?
Can you share your code (keymap directory)?

@chrismetcalf
Copy link
Author

Uninstalled Karabiner and disabled KeyboardMaestro and the problem has persisted.

My keymap directory is in my fork: https://github.com/chrismetcalf/qmk_firmware/tree/master/keyboards/dm9records/plaid/keymaps/chrismetcalf

@spidey3
Copy link
Contributor

spidey3 commented Jan 24, 2021

Looking at your code, I don't see anything that jumps out as likely to cause the keyboard to crash...
Does the problem happen when plugged into a different host, or when using a different port?

@chrismetcalf
Copy link
Author

I've tried different ports, and I just tried another Mac and got the same results.

@spidey3
Copy link
Contributor

spidey3 commented Jan 25, 2021

This seems similar in some ways to the issues mentioned in #11389

@chrismetcalf
Copy link
Author

@spidey3 The sluggish/repeating issue sounds exactly like #11389. I'll try cherry-picking my layout file onto 0.10.54 and see if the issue(s) go away.

@chrismetcalf
Copy link
Author

It appears that my keymap, cherry-picked on top of 0.10.54, is stable! 👍

@spidey3
Copy link
Contributor

spidey3 commented Jan 26, 2021

Can you please try it on 0.11.0?

@chrismetcalf
Copy link
Author

0.11.0 seems to be stable as well 🎉

@spidey3
Copy link
Contributor

spidey3 commented Jan 26, 2021

0.11.0 seems to be stable as well 🎉

Hmm. Can you try the following versions:

  • 0.11.43
  • 0.11.18
  • 0.11.15

@chrismetcalf
Copy link
Author

I'll give them a try but I should let you know that 0.11.0 did end up locking up three times this morning - once after my laptop resumed from sleep, and twice again later on after a longer delay than I was seeing with HEAD. I also saw the key repeat issue once.

But the situation is somewhat improved and at least I'm able to use my keyboard again for work.

@spidey3
Copy link
Contributor

spidey3 commented Jan 26, 2021

Hmm. So it still seems like the problem started at the last breaking change. I also think that it is related to vusb, because the only boards that seem to have difficulty are the ones that use vusb.

It would still be nice to see if any of the intermediate versions make any difference.

@MajorKoos
Copy link
Contributor

MajorKoos commented Feb 3, 2021

I'm tracking a similar issue with the port I'm working on for LeeKu PCBs (atmega32a). Setting KEYBOARD_SHARED_EP = no helps with the repeating keystrokes, but half the time when I connect the board to USB it isn't detected by windows.
10.54 seems fine.

@MajorKoos
Copy link
Contributor

MajorKoos commented Feb 10, 2021

Could you test against the current build with this added to your rules.mk file?
SHARED_EP_ENABLE = yes
KEYBOARD_SHARED_EP = yes

@chrismetcalf
Copy link
Author

@MajorKoos Long delay (with a lot of unplugging and replugging) getting back to this, but I just enabled those two options and I've made it like 2 hours now without a freeze, which is longer than I've made it in a long time.

LED1 is stuck on, but otherwise everything seems fine

@chrismetcalf
Copy link
Author

Still working as of this morning, so those new rules seem to have done the trick. I'm on SHA 986b208ce12d084ef052b2dc8b5d086bdb0fca13, if it matters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants