I’m currently experiencing a problem where I can’t access the bootloader; this is preventing me from flashing the keyboard using the following methods:
1) Bootmagic reset: Hold down the key at (0,0) in the matrix (usually the top left key or Escape) and plug in the keyboard.
2) Physical reset button: Briefly press the button on the back of the PCB - some may have pads you must short instead.
3) Keycode in layout: Press the key mapped to QK_BOOT if it is available.
The only method that works is flashing using a USBasp device and a tag connect cable.
I was using method (1) to flash because the others never worked. I used the following command to flash:
user $ make system76/launch_2:default:dfu
Everything was working fine for the first 15-20 flashes, but after one flash, the board bricked. There were no error messages in the console and it stated it successfully wrote the compiled hex file; the only hint that something went wrong was that it could not verify the file after flashing.
To fix it, I deleted then re-cloned the repository to remove all changes I made. Then, I ran:
user $ make system76/launch_2:default:productionuser $ avrdude -c usbasp -p at90usb646 -U flash:w:system76_launch_2_default_production.hex
It flashed with no errors, but the bootloader still seemed to be broken; I can’t use methods 1-3 to flash. Usually, when I use method (1), the bootloader shows up as a device – it no longer does. This is with unmodified, stock source-code cloned directly from the GitHub.
Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.1
Ψ QMK home: /home/user/Desktop/System76_QMK/qmk_firmware
Ψ Detected Linux.
Ψ Git branch: master
Ψ Repo version: 0.19.12
⚠ Git has unstashed/uncommitted changes.
⚠ The official repository does not seem to be configured as git remote "upstream".
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 10.3.1
Ψ Found avr-gcc version 5.4.0
Ψ Found avrdude version 7.1-2023040
Ψ Found dfu-util version 0.9
Ψ Found dfu-programmer version 0.6.1
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2022-09-18 10:01:17 +0000 -- (0e9d558b5)
Ψ - lib/chibios-contrib: 2022-10-03 18:09:41 +0200 -- (bb8356fb)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 -- (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 -- (549b97320)
Ψ - lib/pico-sdk: 2022-09-19 18:02:44 +0200 -- (8d56ea3)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 -- (c2e3b4e)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 -- (819dbc1)
Ψ QMK is ready to go, but minor problems were found
Is AutoHotKey / Karabiner installed
[ ] AutoHotKey (Windows)
[ ] Karabiner (macOS)
Other keyboard-related software installed
No response
Additional Context
This is actually the second time I’ve bricked the keyboard. The first time was when I was trying to use the official QMK repository because System76’s fork used an older version and didn’t support the latest features. I also didn’t have a USBasp device nor a tag connect cable, so I talked to support to try and fix it. In the end, I sent it in for repair and got it back working as before (the keyboard and bootloader were fixed). By the way, 10/10 to the support team and engineers who fixed it and left a cute note inside the box. =D
Side note: Accessing the bootloader using method (3) never worked even though it’s implemented in the default setup… might need to open a separate issue for that. I’d rather push a button than unplug and re-plug the keyboard every time I want to test a new setup.
I have no idea why the keyboard is acting the way it is, I’ve spent many hours in forms, wikis, repositories, etc. to try and fix it. I don’t “think” I have a defective unit because I got it back working from RMA. For now, I have it “functional” using firmware flashed using the ISP on the board; but the bootloader still doesn’t work.
Out of curiosity, I ran System76’s keyboard configurator to see what happens. It’s able to see the keyboard, but any changes made inside the configurator are not saved to the keyboard after unplugging and re-plugging it. Additionally, when the keyboard bricked, it caused my mouse to stop responding; I had to reboot to fix it.
I love the keyboard; I really want to get it working properly, but I don’t want to bother support again.
Describe the Bug
Hello maintainers,
Problem:
I’m currently experiencing a problem where I can’t access the bootloader; this is preventing me from flashing the keyboard using the following methods:
1) Bootmagic reset: Hold down the key at (0,0) in the matrix (usually the top left key or Escape) and plug in the keyboard.
2) Physical reset button: Briefly press the button on the back of the PCB - some may have pads you must short instead.
3) Keycode in layout: Press the key mapped to
QK_BOOTif it is available.The only method that works is flashing using a USBasp device and a tag connect cable.
How the problem started:
I was using System76’s fork of the QMK firmware to make my custom setup: https://github.com/system76/qmk_firmware/tree/master/keyboards/system76/launch_2
I was using method (1) to flash because the others never worked. I used the following command to flash:
user $ make system76/launch_2:default:dfuEverything was working fine for the first 15-20 flashes, but after one flash, the board bricked. There were no error messages in the console and it stated it successfully wrote the compiled hex file; the only hint that something went wrong was that it could not verify the file after flashing.
To fix it, I deleted then re-cloned the repository to remove all changes I made. Then, I ran:
user $ make system76/launch_2:default:productionuser $ avrdude -c usbasp -p at90usb646 -U flash:w:system76_launch_2_default_production.hexIt flashed with no errors, but the bootloader still seemed to be broken; I can’t use methods 1-3 to flash. Usually, when I use method (1), the bootloader shows up as a device – it no longer does. This is with unmodified, stock source-code cloned directly from the GitHub.
Keyboard Used
system76/launch_2
Link to product page (if applicable)
https://system76.com/accessories/launch
Operating System
Linux Mint 21.1 x86_64
qmk doctor Output
Is AutoHotKey / Karabiner installed
Other keyboard-related software installed
No response
Additional Context
This is actually the second time I’ve bricked the keyboard. The first time was when I was trying to use the official QMK repository because System76’s fork used an older version and didn’t support the latest features. I also didn’t have a USBasp device nor a tag connect cable, so I talked to support to try and fix it. In the end, I sent it in for repair and got it back working as before (the keyboard and bootloader were fixed). By the way, 10/10 to the support team and engineers who fixed it and left a cute note inside the box. =D
Side note: Accessing the bootloader using method (3) never worked even though it’s implemented in the default setup… might need to open a separate issue for that. I’d rather push a button than unplug and re-plug the keyboard every time I want to test a new setup.
I have no idea why the keyboard is acting the way it is, I’ve spent many hours in forms, wikis, repositories, etc. to try and fix it. I don’t “think” I have a defective unit because I got it back working from RMA. For now, I have it “functional” using firmware flashed using the ISP on the board; but the bootloader still doesn’t work.
Out of curiosity, I ran System76’s keyboard configurator to see what happens. It’s able to see the keyboard, but any changes made inside the configurator are not saved to the keyboard after unplugging and re-plugging it. Additionally, when the keyboard bricked, it caused my mouse to stop responding; I had to reboot to fix it.
I love the keyboard; I really want to get it working properly, but I don’t want to bother support again.