You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just received a hillside48 with a Sea Micro atmega32u4 USB-C microcontroller (ordered on beekeeb), and I experienced some challenges uploading the QMK firmware using DFU. I think I have solved the problem (or at least found a workaround), but I still have not gotten around to solder the keys to my keyboard and tested it, so I will have to write a update once that is completed.
Tldr: use avrdude to flash the MCU
I think this issue is with QMK or the microcontroller, but for now I wanted to add it here. Perhaps something could be written about it in the documentation.
My problem was when running the qmk flash command.
~ qmk flash
Ψ Compiling keymap with make -r -R -f builddefs/build_keyboard.mk -s flash KEYBOARD=hillside/48/0_1 KEYMAP=gbthreepwood KEYBOARD_FILESAFE=hillside_48_0_1 TARGET=hillside_48_0_1_gbthreepwood INTERMEDIATE_OUTPUT=.build/obj_hillside_48_0_1_gbthreepwood VERBOSE=false COLOR=true SILENT=false QMK_BIN="qmk"
avr-gcc (GCC) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Size before:
text data bss dec hex filename
0 18082 0 18082 46a2 hillside_48_0_1_gbthreepwood.hex
Copying hillside_48_0_1_gbthreepwood.hex to qmk_firmware folder [OK]
Checking file size of hillside_48_0_1_gbthreepwood.hex [OK]
* The firmware size is fine - 18082/28672 (63%, 10590 bytes free)
Flashing for bootloader: atmel-dfu
Bootloader Version: 0x00 (0)
Checking memory from 0x0 to 0x6FFF... Empty.
Chip already blank, to force erase use --force.
Checking memory from 0x0 to 0x46FF... Empty.
0% 100% Programming 0x4700 bytes...
[ X ERROR
Memory write error, use debug for more info.
make: *** [platforms/avr/flash.mk:173: flash] Error 254
Directly calling the dfu-programmer software gives the same error:
dfu-programmer atmega32u4 flash hillside_48_0_1_gbthreepwood.hex --debug 2
target: atmega32u4
chip_id: 0x2ff4
vendor_id: 0x03eb
command: flash
quiet: false
debug: 2
device_type: AVR
------ command specific below ------
validate: true
hex file: hillside_48_0_1_gbthreepwood.hex
Checking memory from 0x0 to 0x46FF... Empty.
0% 100% Programming 0x4700 bytes...
[ X ERROR
Memory write error, use debug for more info.
The following works, and afterwards it seems that the qmk flash also started working:
avrdude warning: USB bDeviceClass = 255 (expected 254)
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9587 (probably m32u4)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: processing -U flash:w:hillside_48_0_1_gbthreepwood.hex:i
avrdude: reading input file hillside_48_0_1_gbthreepwood.hex for flash
with 18082 bytes in 1 section within [0, 0x46a1]
using 142 pages and 94 pad bytes
avrdude: writing 18082 bytes flash ...
Writing | ################################################## | 100% 1.12 s
avrdude: 18082 bytes of flash written
avrdude: verifying flash memory against hillside_48_0_1_gbthreepwood.hex
Reading | ################################################## | 100% 0.44 s
avrdude: 18082 bytes of flash verified
avrdude done. Thank you.
I now get the following upon issuing qmk flash:
Ψ Compiling keymap with make -r -R -f builddefs/build_keyboard.mk -s flash KEYBOARD=hillside/48/0_1 KEYMAP=gbthreepwood KEYBOARD_FILESAFE=hillside_48_0_1 TARGET=hillside_48_0_1_gbthreepwood INTERMEDIATE_OUTPUT=.build/obj_hillside_48_0_1_gbthreepwood VERBOSE=false COLOR=true SILENT=false QMK_BIN="qmk"
avr-gcc (GCC) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Size before:
text data bss dec hex filename
0 18082 0 18082 46a2 hillside_48_0_1_gbthreepwood.hex
Copying hillside_48_0_1_gbthreepwood.hex to qmk_firmware folder [OK]
Checking file size of hillside_48_0_1_gbthreepwood.hex [OK]
* The firmware size is fine - 18082/28672 (63%, 10590 bytes free)
Flashing for bootloader: atmel-dfu
Bootloader Version: 0x00 (0)
Checking memory from 0x0 to 0x6FFF... Not blank at 0x1.
Erasing flash... Success
Checking memory from 0x0 to 0x6FFF... Empty.
Checking memory from 0x0 to 0x46FF... Empty.
0% 100% Programming 0x4700 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] Success
0% 100% Reading 0x7000 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] Success
Validating... Success
0x4700 bytes written into 0x7000 bytes memory (63.39%).
make: *** [platforms/avr/flash.mk:173: flash] Error 254
There is still a error 254 message, but at least it seems like some uploading did happen.
The text was updated successfully, but these errors were encountered:
After finishing the soldering I can confirm that the firmware is working as expected with the workaround in the above issue.
Unfortunately I used a deflux spray on my PCB which apparently contains acetone, so half of my switches are ruined, but I guess I mostly have myself to blame for that...
I just received a hillside48 with a Sea Micro atmega32u4 USB-C microcontroller (ordered on beekeeb), and I experienced some challenges uploading the QMK firmware using DFU. I think I have solved the problem (or at least found a workaround), but I still have not gotten around to solder the keys to my keyboard and tested it, so I will have to write a update once that is completed.
Tldr: use avrdude to flash the MCU
I think this issue is with QMK or the microcontroller, but for now I wanted to add it here. Perhaps something could be written about it in the documentation.
My problem was when running the
qmk flash
command.Directly calling the
dfu-programmer
software gives the same error:The following works, and afterwards it seems that the
qmk flash
also started working:Output is:
I now get the following upon issuing
qmk flash
:There is still a error 254 message, but at least it seems like some uploading did happen.
The text was updated successfully, but these errors were encountered: