Closed Rovanion closed 6 years ago
I'm using a Teensy 2 ++, the RESET key also doesn't work. But even if the keyboard has been unplugged it still doesn't. After pushing it the keyboard does stop functioning for a few seconds, but then jumps straight back into its usual functional self. Unless I'm supposed to do something else - I have the Teensy app open but it doesn't show it going into dfu mode. Is this related?
For future reference, here is the code that was reported to work with lufa - I'm curious if it has any effect on this.
@DavidBoyes this sounds like your bootloader is a different size than what's in your Makefile - the Teensy ++ requires a different size (1024) there than the Teensy 2.0.
I can confirm this issue on an original Ergodox board (uses Teensy 2.0, should be identical to the EZ line). RESET keycode works when the board is booted, and across multiple resets and reprograms, but as soon as I use the hardware key on the Teensy to put it into bootloader mode, the RESET key no longer works until unplugging the keyboard.
I'm using the latest commit as of this evening (98f0807). I also double-checked my makefile just toconfirm; it's set to the default value of 512, which should be correct for the "regular" Teensy 2.0.
This has been fixed, and I can confirm that it works "as expected"
@drashna I'm still having this issue on a Teensy 2.0 and a fresh QMK install.
This worked for me, thank you Drashna!
@Kyran-C fwiw, the issue for me was that my bootloader was set incorrectly in my config.h. I needed to change from catarina to halfkay for my teensy controller.
under rules.mk. I changed planck/rev5 from BOOTLOADER = qmk-dfu to teensy and it brings back my reset button.
If the the tiny Teensy hardware reset button is used, then firmware defined RESET button can't be used until the keyboard is unplugged and replugged. Once that is done the firmware RESET button works again.
I've just tested this against the current master branch of jackhumbert/qmk_firmware, commit 11c591c, and the issue is present as described above.
This is the issue spawned from the discussion in PR #162 and can trace its lineage through PR #160 and Issue #112.