Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem flashing Sea Micro (atmega32u4) using DFU #33

Open
gbThreepwood opened this issue Feb 7, 2024 · 1 comment
Open

Problem flashing Sea Micro (atmega32u4) using DFU #33

gbThreepwood opened this issue Feb 7, 2024 · 1 comment

Comments

@gbThreepwood
Copy link

gbThreepwood commented Feb 7, 2024

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 -p atmega32u4 -c flip1 -U flash:w:hillside_48_0_1_gbthreepwood.hex

Output is:

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.

@gbThreepwood
Copy link
Author

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant