2017-07-03 14:30:36 +06:00
# Frequently Asked Build Questions
2018-02-20 01:09:05 +06:00
This page covers questions about building QMK. If you haven't yet done so, you should read the [Build Environment Setup ](getting_started_build_tools.md ) and [Make Instructions ](getting_started_make_guide.md ) guides.
2015-01-14 06:15:50 +06:00
2017-12-09 11:36:32 +06:00
## Can't Program on Linux
2018-02-20 01:09:05 +06:00
You will need proper permissions to operate a device. For Linux users, see the instructions regarding `udev` rules, below. If you have issues with `udev` , a work-around is to use the `sudo` command. If you are not familiar with this command, check its manual with `man sudo` or [see this webpage ](https://linux.die.net/man/8/sudo ).
2015-11-27 07:56:20 +06:00
2018-02-20 01:09:05 +06:00
An example of using `sudo` , when your controller is ATMega32u4:
2017-12-09 11:56:58 +06:00
2015-11-27 07:56:20 +06:00
$ sudo dfu-programmer atmega32u4 erase --force
2015-11-27 07:59:33 +06:00
$ sudo dfu-programmer atmega32u4 flash your.hex
2015-11-27 07:56:20 +06:00
$ sudo dfu-programmer atmega32u4 reset
2018-02-20 01:09:05 +06:00
or just:
2015-11-27 07:56:20 +06:00
2017-10-15 03:32:19 +06:00
$ sudo make < keyboard > :< keymap > :dfu
2015-11-27 07:56:20 +06:00
2019-03-19 03:22:02 +06:00
Note that running `make` with `sudo` is generally ** *not*** a good idea, and you should use one of the former methods, if possible.
2015-01-14 06:35:19 +06:00
2018-10-20 21:40:32 +06:00
### Linux `udev` Rules
2018-02-20 01:09:05 +06:00
On Linux, you'll need proper privileges to access the MCU. You can either use
2019-08-01 22:20:31 +06:00
`sudo` when flashing firmware, or place these files in `/etc/udev/rules.d/` . Once added run the following:
```console
sudo udevadm control --reload-rules
sudo udevadm trigger
```
2015-01-14 06:35:19 +06:00
**/etc/udev/rules.d/50-atmel-dfu.rules:**
```
# Atmel ATMega32U4
2020-06-07 14:06:55 +06:00
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff4", TAG+="uaccess", RUN{builtin}+="uaccess"
2015-01-14 06:35:19 +06:00
# Atmel USBKEY AT90USB1287
2020-06-07 14:06:55 +06:00
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ffb", TAG+="uaccess", RUN{builtin}+="uaccess"
2015-01-14 06:35:19 +06:00
# Atmel ATMega32U2
2020-06-07 14:06:55 +06:00
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff0", TAG+="uaccess", RUN{builtin}+="uaccess"
2015-01-14 06:35:19 +06:00
```
2019-03-27 21:42:03 +06:00
**/etc/udev/rules.d/54-input-club-keyboard.rules:**
```
# Input Club keyboard bootloader
2020-06-07 14:06:55 +06:00
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1c11", ATTRS{idProduct}=="b007", TAG+="uaccess", RUN{builtin}+="uaccess"
2019-03-27 21:42:03 +06:00
```
2015-05-09 10:33:56 +06:00
2019-11-28 21:29:11 +06:00
**/etc/udev/rules.d/55-caterina.rules:**
2019-08-01 22:20:31 +06:00
```
# ModemManager should ignore the following devices
2020-06-07 14:06:55 +06:00
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2a03", ATTRS{idProduct}=="0036", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0036", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="9205", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="9203", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
2019-08-01 22:20:31 +06:00
```
2020-06-07 14:06:55 +06:00
**Note:** With older (before 1.12) ModemManager, filtering only works when not in strict mode, the following commands can update that settings:
2019-08-01 22:20:31 +06:00
```console
2020-07-08 00:22:38 +06:00
printf '[Service]\nExecStart=\nExecStart=/usr/sbin/ModemManager --filter-policy=default' | sudo tee /etc/systemd/system/ModemManager.service.d/policy.conf
2019-08-01 22:20:31 +06:00
sudo systemctl daemon-reload
sudo systemctl restart ModemManager
```
**/etc/udev/rules.d/56-dfu-util.rules:**
```
# stm32duino
2020-06-07 14:06:55 +06:00
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1eaf", ATTRS{idProduct}=="0003", TAG+="uaccess", RUN{builtin}+="uaccess"
2019-08-01 22:20:31 +06:00
# Generic stm32
2020-06-07 14:06:55 +06:00
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", TAG+="uaccess", RUN{builtin}+="uaccess"
2019-08-01 22:20:31 +06:00
```
2019-11-28 21:29:11 +06:00
**/etc/udev/rules.d/57-bootloadhid.rules:**
```
# bootloadHID
2020-06-07 14:06:55 +06:00
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", TAG+="uaccess", RUN{builtin}+="uaccess"
2019-11-28 21:29:11 +06:00
```
2019-02-06 17:57:19 +06:00
### Serial device is not detected in bootloader mode on Linux
2019-02-18 22:50:22 +06:00
Make sure your kernel has appropriate support for your device. If your device uses USB ACM, such as
2019-02-06 17:57:19 +06:00
Pro Micro (Atmega32u4), make sure to include `CONFIG_USB_ACM=y` . Other devices may require `USB_SERIAL` and any of its sub options.
2018-10-20 21:40:32 +06:00
## Unknown Device for DFU Bootloader
2019-08-24 12:38:21 +06:00
Issues encountered when flashing keyboards on Windows are most often due to having the wrong drivers installed for the bootloader, or none at all.
2018-10-20 21:40:32 +06:00
2019-08-24 12:38:21 +06:00
Re-running the QMK installation script (`./util/qmk_install.sh` from the `qmk_firmware` directory in MSYS2 or WSL) or reinstalling the QMK Toolbox may fix the issue. Alternatively, you can download and run the [`qmk_driver_installer` ](https://github.com/qmk/qmk_driver_installer ) package manually.
2019-03-19 03:22:02 +06:00
2019-08-24 12:38:21 +06:00
If that doesn't work, then you may need to download and run Zadig. See [Bootloader Driver Installation with Zadig ](driver_installation_zadig.md ) for more detailed information.
2018-10-20 21:40:32 +06:00
2018-02-20 01:09:05 +06:00
## USB VID and PID
You can use any ID you want with editing `config.h` . Using any presumably unused ID will be no problem in fact except for very low chance of collision with other product.
Most boards in QMK use `0xFEED` as the vendor ID. You should look through other keyboards to make sure you pick a unique Product ID.
Also see this.
https://github.com/tmk/tmk_keyboard/issues/150
You can buy a really unique VID:PID here. I don't think you need this for personal use.
- http://www.obdev.at/products/vusb/license.html
- http://www.mcselec.com/index.php?page=shop.product_details& flypage=shop.flypage& product_id=92& option=com_phpshop& Itemid=1
2015-05-09 10:33:56 +06:00
2015-12-09 11:45:22 +06:00
## BOOTLOADER_SIZE for AVR
Note that Teensy2.0++ bootloader size is 2048byte. Some Makefiles may have wrong comment.
```
2017-12-09 11:56:58 +06:00
# Boot Section Size in *bytes*
# Teensy halfKay 512
# Teensy++ halfKay 2048
2015-12-09 11:45:22 +06:00
# Atmel DFU loader 4096 (TMK Alt Controller)
2017-12-09 11:56:58 +06:00
# LUFA bootloader 4096
# USBaspLoader 2048
2015-12-09 11:45:22 +06:00
OPT_DEFS += -DBOOTLOADER_SIZE=2048
2017-07-03 14:30:36 +06:00
```
2018-03-26 05:44:17 +06:00
## `avr-gcc: internal compiler error: Abort trap: 6 (program cc1)` on MacOS
2020-04-21 06:35:40 +06:00
2019-02-18 22:50:22 +06:00
This is an issue with updating on brew, causing symlinks that avr-gcc depend on getting mangled.
2018-03-26 05:44:17 +06:00
2019-02-18 22:50:22 +06:00
The solution is to remove and reinstall all affected modules.
2018-03-26 05:44:17 +06:00
```
2020-04-21 06:35:40 +06:00
brew rm avr-gcc avr-gcc@8 dfu-programmer dfu-util gcc-arm-none-eabi arm-gcc-bin@8 avrdude qmk
brew install qmk/qmk/qmk
2019-12-31 20:33:54 +06:00
brew link --force avr-gcc@8
brew link --force arm-gcc-bin@8
2018-03-26 05:44:17 +06:00
```
2018-07-08 06:37:37 +06:00
2019-12-31 20:33:54 +06:00
### `avr-gcc` and LUFA
2018-07-08 06:37:37 +06:00
2019-12-31 20:33:54 +06:00
If you updated your `avr-gcc` and you see errors involving LUFA, for example:
2018-07-08 06:37:37 +06:00
`lib/lufa/LUFA/Drivers/USB/Class/Device/AudioClassDevice.h:380:5: error: 'const' attribute on function returning 'void'`
2019-12-31 20:33:54 +06:00
For now, you need to rollback `avr-gcc` to 8 in Homebrew.
2018-07-08 06:37:37 +06:00
```
brew uninstall --force avr-gcc
2019-06-05 23:53:11 +06:00
brew install avr-gcc@8
brew link --force avr-gcc@8
2018-07-08 06:37:37 +06:00
```
2019-02-18 22:50:22 +06:00
### I just flashed my keyboard and it does nothing/keypresses don't register - it's also ARM (rev6 planck, clueboard 60, hs60v2, etc...) (Feb 2019)
Due to how EEPROM works on ARM based chips, saved settings may no longer be valid. This affects the default layers, and *may* , under certain circumstances we are still figuring out, make the keyboard unusable. Resetting the EEPROM will correct this.
[Planck rev6 reset EEPROM ](https://cdn.discordapp.com/attachments/473506116718952450/539284620861243409/planck_rev6_default.bin ) can be used to force an eeprom reset. After flashing this image, flash your normal firmware again which should restore your keyboard to _normal_ working order.
[Preonic rev3 reset EEPROM ](https://cdn.discordapp.com/attachments/473506116718952450/537849497313738762/preonic_rev3_default.bin )
If bootmagic is enabled in any form, you should be able to do this too (see [Bootmagic docs ](feature_bootmagic.md ) and keyboard info for specifics on how to do this).