1 files changed, 11 insertions, 264 deletions
diff --git a/docs/newbs_flashing.md b/docs/newbs_flashing.md
index 428e698e2..3cbeb1c4b 100644
--- a/docs/newbs_flashing.md
+++ b/docs/newbs_flashing.md
@@ -86,13 +86,13 @@ Click the `Flash` button in QMK Toolbox. You will see output similar to the foll
 ## Flash your Keyboard from the Command Line
-This has been made pretty simple compared to what it used to be.  When you are ready to compile and flash your firmware, open up your terminal window and run the build command: 
+This has been made pretty simple compared to what it used to be.  When you are ready to compile and flash your firmware, open up your terminal window and run the flash command: 
-    make <my_keyboard>:<my_keymap>:flash
+    qmk flash
-For example, if your keymap is named "xyverz" and you're building a keymap for a rev5 planck, you'll use this command:
+If you have not configured your keyboard/keymap name, or you have multiple keyboards, you can specify the keyboard and keymap:
-    make planck/rev5:xyverz:flash
+    qmk flash -kb <my_keyboard> -km <my_keymap>
 This will check the keyboard's configuration, and then attempt to flash it based on the specified bootloader.  This means that you don't need to know which bootloader that your keyboard uses.  Just run the command, and let the command do the heavy lifting.
@@ -106,273 +106,20 @@ There are five main bootloaders that are used. Pro Micro and clones use Caterina
 You can find more information about the bootloaders in the [Flashing Instructions and Bootloader Information](flashing.md) page. 
-If you know what bootloader that you're using, then when compiling the firmware, you can actually add some extra text to the `make` command to automate the flashing process. 
+If you know what bootloader that you're using you can specify that in your flash command:
-### DFU
+    qmk flash -bl <bootloader>
-For the DFU bootloader, when you're ready to compile and flash your firmware, open up your terminal window and run the build command: 
+Run this command to get a list of valid bootloaders:
-    make <my_keyboard>:<my_keymap>:dfu
+    qmk flash --bootloaders
-For example, if your keymap is named "xyverz" and you're building a keymap for a rev5 planck, you'll use this command:
+### More information
-    make planck/rev5:xyverz:dfu
+See the Flashing documentation for more information on esoteric flashing situations.
-Once it finishes compiling, it should output the following:
-```
-Linking: .build/planck_rev5_xyverz.elf                                                              [OK]
-Creating load file for flashing: .build/planck_rev5_xyverz.hex                                      [OK]
-Copying planck_rev5_xyverz.hex to qmk_firmware folder                                               [OK]
-Checking file size of planck_rev5_xyverz.hex                                                        
- * File size is fine - 18574/28672
- ```
-After it gets to this point, the build script will look for the DFU bootloader every 5 seconds.  It will repeat the following until the device is found or you cancel it. 
-    dfu-programmer: no device present.
-    Error: Bootloader not found. Trying again in 5s.
-Once it does this, you'll want to reset the controller.  It should then show output similar to this: 
-```
-*** Attempting to flash, please don't remove device
->>> dfu-programmer atmega32u4 erase --force
-    Erasing flash...  Success
-    Checking memory from 0x0 to 0x6FFF...  Empty.
->>> dfu-programmer atmega32u4 flash /Users/skully/qmk_firmware/clueboard_66_hotswap_gen1_skully.hex
-    Checking memory from 0x0 to 0x55FF...  Empty.
-    0%                            100%  Programming 0x5600 bytes...
-    [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
-    0%                            100%  Reading 0x7000 bytes...
-    [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
-    Validating...  Success
-    0x5600 bytes written into 0x7000 bytes memory (76.79%).
->>> dfu-programmer atmega32u4 reset
-```
-?> If you have any issues with this - such as `dfu-programmer: no device present` - please see the [Frequently Asked Build Questions](faq_build.md).
-#### DFU commands
-There are a number of DFU commands that you can use to flash firmware to a DFU device:
-* `:dfu` - This is the normal option and waits until a DFU device is available, and then flashes the firmware. This will check every 5 seconds, to see if a DFU device has appeared.
-* `:dfu-ee` - This flashes an `eep` file instead of the normal hex.  This is uncommon. 
-* `:dfu-split-left` - This flashes the normal firmware, just like the default option (`:dfu`). However, this also flashes the "Left Side" EEPROM file for split keyboards. _This is ideal for Elite C based split keyboards._
-* `:dfu-split-right` - This flashes the normal firmware, just like the default option (`:dfu`). However, this also flashes the "Right Side" EEPROM file for split keyboards. _This is ideal for Elite C based split keyboards._
-### Caterina 
-For Arduino boards and their clones (such as the SparkFun ProMicro), when you're ready to compile and flash your firmware, open up your terminal window and run the build command: 
-    make <my_keyboard>:<my_keymap>:avrdude
-For example, if your keymap is named "xyverz" and you're building a keymap for a rev2 Lets Split, you'll use this command:
-    make lets_split/rev2:xyverz:avrdude
-Once the firmware finishes compiling, it will output something like this: 
-```
-Linking: .build/lets_split_rev2_xyverz.elf                                                            [OK]
-Creating load file for flashing: .build/lets_split_rev2_xyverz.hex                                    [OK]
-Checking file size of lets_split_rev2_xyverz.hex                                                      [OK]
- * File size is fine - 27938/28672
-Detecting USB port, reset your controller now..............
-```
-At this point, reset the board and then the script will detect the bootloader and then flash the board.  The output should look something like this: 
-```
-Detected controller on USB port at /dev/ttyS15
-Connecting to programmer: .
-Found programmer: Id = "CATERIN"; type = S
-    Software Version = 1.0; No Hardware Version given.
-Programmer supports auto addr increment.
-Programmer supports buffered memory access with buffersize=128 bytes.
-Programmer supports the following devices:
-    Device code: 0x44
-avrdude.exe: AVR device initialized and ready to accept instructions
-Reading | ################################################## | 100% 0.00s
-avrdude.exe: Device signature = 0x1e9587 (probably m32u4)
-avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
-             To disable this feature, specify the -D option.
-avrdude.exe: erasing chip
-avrdude.exe: reading input file "./.build/lets_split_rev2_xyverz.hex"
-avrdude.exe: input file ./.build/lets_split_rev2_xyverz.hex auto detected as Intel Hex
-avrdude.exe: writing flash (27938 bytes):
-Writing | ################################################## | 100% 2.40s
-avrdude.exe: 27938 bytes of flash written
-avrdude.exe: verifying flash memory against ./.build/lets_split_rev2_xyverz.hex:
-avrdude.exe: load data flash data from input file ./.build/lets_split_rev2_xyverz.hex:
-avrdude.exe: input file ./.build/lets_split_rev2_xyverz.hex auto detected as Intel Hex
-avrdude.exe: input file ./.build/lets_split_rev2_xyverz.hex contains 27938 bytes
-avrdude.exe: reading on-chip flash data:
-Reading | ################################################## | 100% 0.43s
-avrdude.exe: verifying ...
-avrdude.exe: 27938 bytes of flash verified
-avrdude.exe: safemode: Fuses OK (E:CB, H:D8, L:FF)
-avrdude.exe done.  Thank you.
-```
-If you have any issues with this, you may need to this: 
-    sudo make <my_keyboard>:<my_keymap>:avrdude
-#### Caterina commands
-There are a number of DFU commands that you can use to flash firmware to a DFU device:
-* `:avrdude` - This is the normal option which waits until a Caterina device is available (by detecting a new COM port), and then flashes the firmware.
-* `:avrdude-loop` - This runs the same command as `:avrdude`, but after each device is flashed, it will attempt to flash again.  This is useful for bulk flashing. _This requires you to manually escape the loop by hitting Control+C._
-* `:avrdude-split-left` - This flashes the normal firmware, just like the default option (`:avrdude`). However, this also flashes the "Left Side" EEPROM file for split keyboards. _This is ideal for Pro Micro based split keyboards._
-* `:avrdude-split-right` - This flashes the normal firmware, just like the default option (`:avrdude`). However, this also flashes the "Right Side" EEPROM file for split keyboards. _This is ideal for Pro Micro based split keyboards._
-### HalfKay
-For the PJRC devices (Teensy's), when you're ready to compile and flash your firmware, open up your terminal window and run the build command: 
-    make <my_keyboard>:<my_keymap>:teensy
-For example, if your keymap is named "xyverz" and you're building a keymap for an Ergodox or Ergodox EZ, you'll use this command:
-    make ergodox_ez:xyverz:teensy
-Once the firmware finishes compiling, it will output something like this: 
-```
-Linking: .build/ergodox_ez_xyverz.elf                                                               [OK]
-Creating load file for flashing: .build/ergodox_ez_xyverz.hex                                       [OK]
-Checking file size of ergodox_ez_xyverz.hex                                                         [OK]
- * File size is fine - 25584/32256
- Teensy Loader, Command Line, Version 2.1
-Read "./.build/ergodox_ez_xyverz.hex": 25584 bytes, 79.3% usage
-Waiting for Teensy device...
- (hint: press the reset button)
- ```
- At this point, reset your board.  Once you've done that, you'll see output like this: 
- ```
- Found HalfKay Bootloader
-Read "./.build/ergodox_ez_xyverz.hex": 28532 bytes, 88.5% usage
-Programming............................................................................................................................................................................
-...................................................
-Booting
-```
-### STM32 (ARM)
-For a majority of ARM boards (including the Proton C, Planck Rev 6, and Preonic Rev 3), when you're ready to compile and flash your firmware, open up your terminal window and run the build command: 
-    make <my_keyboard>:<my_keymap>:dfu-util
-For example, if your keymap is named "xyverz" and you're building a keymap for the Planck Revision 6 keyboard, you'll use this command and then reboot the keyboard to the bootloader (before it finishes compiling):
-    make planck/rev6:xyverz:dfu-util
-Once the firmware finishes compiling, it will output something like this: 
-```
-Linking: .build/planck_rev6_xyverz.elf                                                             [OK]
-Creating binary load file for flashing: .build/planck_rev6_xyverz.bin                               [OK]
-Creating load file for flashing: .build/planck_rev6_xyverz.hex                                     [OK]
-Size after:
-   text    data     bss     dec     hex filename
-      0   41820       0   41820    a35c .build/planck_rev6_xyverz.hex
-Copying planck_rev6_xyverz.bin to qmk_firmware folder                                              [OK]
-dfu-util 0.9
-Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
-Copyright 2010-2016 Tormod Volden and Stefan Schmidt
-This program is Free Software and has ABSOLUTELY NO WARRANTY
-Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
-Invalid DFU suffix signature
-A valid DFU suffix will be required in a future dfu-util release!!!
-Opening DFU capable USB device...
-ID 0483:df11
-Run-time device DFU version 011a
-Claiming USB DFU Interface...
-Setting Alternate Setting #0 ...
-Determining device status: state = dfuERROR, status = 10
-dfuERROR, clearing status
-Determining device status: state = dfuIDLE, status = 0
-dfuIDLE, continuing
-DFU mode device DFU version 011a
-Device returned transfer size 2048
-DfuSe interface name: "Internal Flash  "
-Downloading to address = 0x08000000, size = 41824
-Download        [=========================] 100%        41824 bytes
-Download done.
-File downloaded successfully
-Transitioning to dfuMANIFEST state
-```
-#### STM32 Commands
-There are a number of DFU commands that you can use to flash firmware to a STM32 device:
-* `:dfu-util` - The default command for flashing to STM32 devices, and will wait until an STM32 bootloader is present. . 
-* `:dfu-util-split-left` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Left Side" EEPROM setting for split keyboards.
-* `:dfu-util-split-right` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Right Side" EEPROM setting for split keyboards.
-* `:st-link-cli` - This allows you to flash the firmware via ST-LINK's CLI utility, rather than dfu-util. 
-### BootloadHID
-For Bootmapper Client(BMC)/bootloadHID/ATmega32A based boards, when you're ready to compile and flash your firmware, open up your terminal window and run the build command: 
-    make <my_keyboard>:<my_keymap>:bootloaderHID
-For example, if your keymap is named "xyverz" and you're building a keymap for a jj40, you'll use this command:
-    make jj40:xyverz:bootloaderHID
-Once the firmware finishes compiling, it will output something like this: 
-```
-Linking: .build/jj40_default.elf                                                                   [OK]
-Creating load file for flashing: .build/jj40_default.hex                                           [OK]
-Copying jj40_default.hex to qmk_firmware folder                                                    [OK]
-Checking file size of jj40_default.hex                                                             [OK]
- * The firmware size is fine - 21920/28672 (6752 bytes free)
-```
-After it gets to this point, the build script will look for the DFU bootloader every 5 seconds.  It will repeat the following until the device is found or you cancel it. 
-```
-Error opening HIDBoot device: The specified device was not found
-Trying again in 5s.
-```
-Once it does this, you'll want to reset the controller.  It should then show output similar to this: 
-```
-Page size   = 128 (0x80)
-Device size = 32768 (0x8000); 30720 bytes remaining
-Uploading 22016 (0x5600) bytes starting at 0 (0x0)
-0x05580 ... 0x05600
-```
 ## Test It Out!
 Congrats! Your custom firmware has been programmed to your keyboard!
-Give it a try and make sure everything works the way you want it to. We've written [Testing and Debugging](newbs_testing_debugging.md) to round out this Newbie Guide, so head over there to learn about how to troubleshoot your custom functionality.
+Give it a try and make sure everything works the way you want it to. We've written [Testing and Debugging](newbs_testing_debugging.md) to round out this Newbie Guide, so head over there to learn about validating your firmware and how to troubleshoot your custom functionality.

diff --git a/docs/newbs_flashing.md b/docs/newbs_flashing.md index 428e698e2..3cbeb1c4b 100644 --- a/docs/newbs_flashing.md +++ b/docs/newbs_flashing.md
@@ -86,13 +86,13 @@ Click the `Flash` button in QMK Toolbox. You will see output similar to the foll
86		86
87	## Flash your Keyboard from the Command Line	87	## Flash your Keyboard from the Command Line
88		88
89	This has been made pretty simple compared to what it used to be. When you are ready to compile and flash your firmware, open up your terminal window and run the build command:	89	This has been made pretty simple compared to what it used to be. When you are ready to compile and flash your firmware, open up your terminal window and run the flash command:
90		90
91	make <my_keyboard>:<my_keymap>:flash	91	qmk flash
92		92
93	For example, if your keymap is named "xyverz" and you're building a keymap for a rev5 planck, you'll use this command:	93	If you have not configured your keyboard/keymap name, or you have multiple keyboards, you can specify the keyboard and keymap:
94		94
95	make planck/rev5:xyverz:flash	95	qmk flash -kb <my_keyboard> -km <my_keymap>
96		96
97	This will check the keyboard's configuration, and then attempt to flash it based on the specified bootloader. This means that you don't need to know which bootloader that your keyboard uses. Just run the command, and let the command do the heavy lifting.	97	This will check the keyboard's configuration, and then attempt to flash it based on the specified bootloader. This means that you don't need to know which bootloader that your keyboard uses. Just run the command, and let the command do the heavy lifting.
98		98
@@ -106,273 +106,20 @@ There are five main bootloaders that are used. Pro Micro and clones use Caterina
106		106
107	You can find more information about the bootloaders in the [Flashing Instructions and Bootloader Information](flashing.md) page.	107	You can find more information about the bootloaders in the [Flashing Instructions and Bootloader Information](flashing.md) page.
108		108
109	If you know what bootloader that you're using, then when compiling the firmware, you can actually add some extra text to the `make` command to automate the flashing process.	109	If you know what bootloader that you're using you can specify that in your flash command:
110		110
111	### DFU	111	qmk flash -bl <bootloader>
112		112
113	For the DFU bootloader, when you're ready to compile and flash your firmware, open up your terminal window and run the build command:	113	Run this command to get a list of valid bootloaders:
114		114
115	make <my_keyboard>:<my_keymap>:dfu	115	qmk flash --bootloaders
116		116
117	For example, if your keymap is named "xyverz" and you're building a keymap for a rev5 planck, you'll use this command:	117	### More information
118		118
119	make planck/rev5:xyverz:dfu	119	See the Flashing documentation for more information on esoteric flashing situations.
120
121	Once it finishes compiling, it should output the following:
122
123	```
124	Linking: .build/planck_rev5_xyverz.elf [OK]
125	Creating load file for flashing: .build/planck_rev5_xyverz.hex [OK]
126	Copying planck_rev5_xyverz.hex to qmk_firmware folder [OK]
127	Checking file size of planck_rev5_xyverz.hex
128	* File size is fine - 18574/28672
129	```
130
131	After it gets to this point, the build script will look for the DFU bootloader every 5 seconds. It will repeat the following until the device is found or you cancel it.
132
133	dfu-programmer: no device present.
134	Error: Bootloader not found. Trying again in 5s.
135
136	Once it does this, you'll want to reset the controller. It should then show output similar to this:
137
138	```
139	*** Attempting to flash, please don't remove device
140	>>> dfu-programmer atmega32u4 erase --force
141	Erasing flash... Success
142	Checking memory from 0x0 to 0x6FFF... Empty.
143	>>> dfu-programmer atmega32u4 flash /Users/skully/qmk_firmware/clueboard_66_hotswap_gen1_skully.hex
144	Checking memory from 0x0 to 0x55FF... Empty.
145	0% 100% Programming 0x5600 bytes...
146	[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] Success
147	0% 100% Reading 0x7000 bytes...
148	[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] Success
149	Validating... Success
150	0x5600 bytes written into 0x7000 bytes memory (76.79%).
151	>>> dfu-programmer atmega32u4 reset
152	```
153
154	?> If you have any issues with this - such as `dfu-programmer: no device present` - please see the [Frequently Asked Build Questions](faq_build.md).
155
156	#### DFU commands
157
158	There are a number of DFU commands that you can use to flash firmware to a DFU device:
159
160	* `:dfu` - This is the normal option and waits until a DFU device is available, and then flashes the firmware. This will check every 5 seconds, to see if a DFU device has appeared.
161	* `:dfu-ee` - This flashes an `eep` file instead of the normal hex. This is uncommon.
162	* `:dfu-split-left` - This flashes the normal firmware, just like the default option (`:dfu`). However, this also flashes the "Left Side" EEPROM file for split keyboards. _This is ideal for Elite C based split keyboards._
163	* `:dfu-split-right` - This flashes the normal firmware, just like the default option (`:dfu`). However, this also flashes the "Right Side" EEPROM file for split keyboards. _This is ideal for Elite C based split keyboards._
164
165
166	### Caterina
167
168	For Arduino boards and their clones (such as the SparkFun ProMicro), when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
169
170	make <my_keyboard>:<my_keymap>:avrdude
171
172	For example, if your keymap is named "xyverz" and you're building a keymap for a rev2 Lets Split, you'll use this command:
173
174	make lets_split/rev2:xyverz:avrdude
175
176	Once the firmware finishes compiling, it will output something like this:
177
178	```
179	Linking: .build/lets_split_rev2_xyverz.elf [OK]
180	Creating load file for flashing: .build/lets_split_rev2_xyverz.hex [OK]
181	Checking file size of lets_split_rev2_xyverz.hex [OK]
182	* File size is fine - 27938/28672
183	Detecting USB port, reset your controller now..............
184	```
185
186	At this point, reset the board and then the script will detect the bootloader and then flash the board. The output should look something like this:
187
188	```
189	Detected controller on USB port at /dev/ttyS15
190
191	Connecting to programmer: .
192	Found programmer: Id = "CATERIN"; type = S
193	Software Version = 1.0; No Hardware Version given.
194	Programmer supports auto addr increment.
195	Programmer supports buffered memory access with buffersize=128 bytes.
196
197	Programmer supports the following devices:
198	Device code: 0x44
199
200	avrdude.exe: AVR device initialized and ready to accept instructions
201
202	Reading \| ################################################## \| 100% 0.00s
203
204	avrdude.exe: Device signature = 0x1e9587 (probably m32u4)
205	avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
206	To disable this feature, specify the -D option.
207	avrdude.exe: erasing chip
208	avrdude.exe: reading input file "./.build/lets_split_rev2_xyverz.hex"
209	avrdude.exe: input file ./.build/lets_split_rev2_xyverz.hex auto detected as Intel Hex
210	avrdude.exe: writing flash (27938 bytes):
211
212	Writing \| ################################################## \| 100% 2.40s
213
214	avrdude.exe: 27938 bytes of flash written
215	avrdude.exe: verifying flash memory against ./.build/lets_split_rev2_xyverz.hex:
216	avrdude.exe: load data flash data from input file ./.build/lets_split_rev2_xyverz.hex:
217	avrdude.exe: input file ./.build/lets_split_rev2_xyverz.hex auto detected as Intel Hex
218	avrdude.exe: input file ./.build/lets_split_rev2_xyverz.hex contains 27938 bytes
219	avrdude.exe: reading on-chip flash data:
220
221	Reading \| ################################################## \| 100% 0.43s
222
223	avrdude.exe: verifying ...
224	avrdude.exe: 27938 bytes of flash verified
225
226	avrdude.exe: safemode: Fuses OK (E:CB, H:D8, L:FF)
227
228	avrdude.exe done. Thank you.
229	```
230	If you have any issues with this, you may need to this:
231
232	sudo make <my_keyboard>:<my_keymap>:avrdude
233
234
235	#### Caterina commands
236
237	There are a number of DFU commands that you can use to flash firmware to a DFU device:
238
239	* `:avrdude` - This is the normal option which waits until a Caterina device is available (by detecting a new COM port), and then flashes the firmware.
240	* `:avrdude-loop` - This runs the same command as `:avrdude`, but after each device is flashed, it will attempt to flash again. This is useful for bulk flashing. _This requires you to manually escape the loop by hitting Control+C._
241	* `:avrdude-split-left` - This flashes the normal firmware, just like the default option (`:avrdude`). However, this also flashes the "Left Side" EEPROM file for split keyboards. _This is ideal for Pro Micro based split keyboards._
242	* `:avrdude-split-right` - This flashes the normal firmware, just like the default option (`:avrdude`). However, this also flashes the "Right Side" EEPROM file for split keyboards. _This is ideal for Pro Micro based split keyboards._
243
244
245	### HalfKay
246
247	For the PJRC devices (Teensy's), when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
248
249	make <my_keyboard>:<my_keymap>:teensy
250
251	For example, if your keymap is named "xyverz" and you're building a keymap for an Ergodox or Ergodox EZ, you'll use this command:
252
253	make ergodox_ez:xyverz:teensy
254
255	Once the firmware finishes compiling, it will output something like this:
256
257	```
258	Linking: .build/ergodox_ez_xyverz.elf [OK]
259	Creating load file for flashing: .build/ergodox_ez_xyverz.hex [OK]
260	Checking file size of ergodox_ez_xyverz.hex [OK]
261	* File size is fine - 25584/32256
262	Teensy Loader, Command Line, Version 2.1
263	Read "./.build/ergodox_ez_xyverz.hex": 25584 bytes, 79.3% usage
264	Waiting for Teensy device...
265	(hint: press the reset button)
266	```
267
268	At this point, reset your board. Once you've done that, you'll see output like this:
269
270	```
271	Found HalfKay Bootloader
272	Read "./.build/ergodox_ez_xyverz.hex": 28532 bytes, 88.5% usage
273	Programming............................................................................................................................................................................
274	...................................................
275	Booting
276	```
277
278	### STM32 (ARM)
279
280	For a majority of ARM boards (including the Proton C, Planck Rev 6, and Preonic Rev 3), when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
281
282	make <my_keyboard>:<my_keymap>:dfu-util
283
284	For example, if your keymap is named "xyverz" and you're building a keymap for the Planck Revision 6 keyboard, you'll use this command and then reboot the keyboard to the bootloader (before it finishes compiling):
285
286	make planck/rev6:xyverz:dfu-util
287
288	Once the firmware finishes compiling, it will output something like this:
289
290	```
291	Linking: .build/planck_rev6_xyverz.elf [OK]
292	Creating binary load file for flashing: .build/planck_rev6_xyverz.bin [OK]
293	Creating load file for flashing: .build/planck_rev6_xyverz.hex [OK]
294
295	Size after:
296	text data bss dec hex filename
297	0 41820 0 41820 a35c .build/planck_rev6_xyverz.hex
298
299	Copying planck_rev6_xyverz.bin to qmk_firmware folder [OK]
300	dfu-util 0.9
301
302	Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
303	Copyright 2010-2016 Tormod Volden and Stefan Schmidt
304	This program is Free Software and has ABSOLUTELY NO WARRANTY
305	Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
306
307	Invalid DFU suffix signature
308	A valid DFU suffix will be required in a future dfu-util release!!!
309	Opening DFU capable USB device...
310	ID 0483:df11
311	Run-time device DFU version 011a
312	Claiming USB DFU Interface...
313	Setting Alternate Setting #0 ...
314	Determining device status: state = dfuERROR, status = 10
315	dfuERROR, clearing status
316	Determining device status: state = dfuIDLE, status = 0
317	dfuIDLE, continuing
318	DFU mode device DFU version 011a
319	Device returned transfer size 2048
320	DfuSe interface name: "Internal Flash "
321	Downloading to address = 0x08000000, size = 41824
322	Download [=========================] 100% 41824 bytes
323	Download done.
324	File downloaded successfully
325	Transitioning to dfuMANIFEST state
326	```
327
328	#### STM32 Commands
329
330	There are a number of DFU commands that you can use to flash firmware to a STM32 device:
331
332	* `:dfu-util` - The default command for flashing to STM32 devices, and will wait until an STM32 bootloader is present. .
333	* `:dfu-util-split-left` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Left Side" EEPROM setting for split keyboards.
334	* `:dfu-util-split-right` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Right Side" EEPROM setting for split keyboards.
335	* `:st-link-cli` - This allows you to flash the firmware via ST-LINK's CLI utility, rather than dfu-util.
336
337
338	### BootloadHID
339
340	For Bootmapper Client(BMC)/bootloadHID/ATmega32A based boards, when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
341
342	make <my_keyboard>:<my_keymap>:bootloaderHID
343
344	For example, if your keymap is named "xyverz" and you're building a keymap for a jj40, you'll use this command:
345
346	make jj40:xyverz:bootloaderHID
347
348	Once the firmware finishes compiling, it will output something like this:
349
350	```
351	Linking: .build/jj40_default.elf [OK]
352	Creating load file for flashing: .build/jj40_default.hex [OK]
353	Copying jj40_default.hex to qmk_firmware folder [OK]
354	Checking file size of jj40_default.hex [OK]
355	* The firmware size is fine - 21920/28672 (6752 bytes free)
356	```
357
358	After it gets to this point, the build script will look for the DFU bootloader every 5 seconds. It will repeat the following until the device is found or you cancel it.
359
360	```
361	Error opening HIDBoot device: The specified device was not found
362	Trying again in 5s.
363	```
364
365	Once it does this, you'll want to reset the controller. It should then show output similar to this:
366
367	```
368	Page size = 128 (0x80)
369	Device size = 32768 (0x8000); 30720 bytes remaining
370	Uploading 22016 (0x5600) bytes starting at 0 (0x0)
371	0x05580 ... 0x05600
372	```
373		120
374	## Test It Out!	121	## Test It Out!
375		122
376	Congrats! Your custom firmware has been programmed to your keyboard!	123	Congrats! Your custom firmware has been programmed to your keyboard!
377		124
378	Give it a try and make sure everything works the way you want it to. We've written [Testing and Debugging](newbs_testing_debugging.md) to round out this Newbie Guide, so head over there to learn about how to troubleshoot your custom functionality.	125	Give it a try and make sure everything works the way you want it to. We've written [Testing and Debugging](newbs_testing_debugging.md) to round out this Newbie Guide, so head over there to learn about validating your firmware and how to troubleshoot your custom functionality.