[Bug] Plaid keyboard freezing after a few minutes

[chrismetcalf]

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]

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

[chrismetcalf]

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]

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]

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

[spidey3]

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

[chrismetcalf]

@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]

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

[spidey3]

Can you please try it on 0.11.0?

[chrismetcalf]

0.11.0 seems to be stable as well 🎉

[spidey3]

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]

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]

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]

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]

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

[chrismetcalf]

@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]

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