search

qmk / qmk_firmware

Open-source keyboard firmware for Atmel AVR and Arm USB families
https://qmk.fm
GNU General Public License v2.0
18.22k stars 39.22k forks source link

[Bug] Error 127 when flashing hands .epp file with DFU bootloader #24427

Closed Franiac closed 2 weeks ago

Franiac commented 1 month ago

Describe the Bug

When flashing my Avalanche v4 with Sea Micro (white) controllers and DFU bootloaders, I get an error at the end:

make: *** [platforms/avr/flash.mk:71: dfu-split-left] Error 127

Here's the complete output:

qmk flash -kb avalanche/v4 -km default -bl dfu-split-left
Ψ Compiling keymap with make -r -R -f builddefs/build_keyboard.mk -s dfu-split-left KEYBOARD=avalanche/v4 KEYMAP=default KEYBOARD_FILESAFE=avalanche_v4 TARGET=avalanche_v4_default VERBOSE=false COLOR=true SILENT=false QMK_BIN="qmk"

Generating: .build/obj_avalanche_v4_default/src/default_keyboard.c                                  [OK]
avr-gcc.exe (GCC) 12.2.0
Copyright (C) 2022 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   22050       0   22050    5622 avalanche_v4_default.hex

Generating: .build/obj_avalanche_v4_default/src/info_config.h                                       [OK]
Generating: .build/obj_avalanche_v4_default/src/default_keyboard.h                                  [OK]
Copying avalanche_v4_default.hex to qmk_firmware folder                                             [OK]
Checking file size of avalanche_v4_default.hex                                                      [OK]
 * The firmware size is fine - 22050/28672 (76%, 6622 bytes free)
Flashing 'eeprom-lefthand.eep' for EE_HANDS split keyboard support.
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 0x7F...  Empty.
0%                            100%  Programming 0x80 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x400 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
Validating...  Success
0x80 bytes written into 0x400 bytes memory (12.50%).
Checking memory from 0x0 to 0x567F...  Empty.
0%                            100%  Programming 0x5680 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x7000 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
Validating...  Success
0x5680 bytes written into 0x7000 bytes memory (77.23%).
make: *** [platforms/avr/flash.mk:71: dfu-split-left] Error 127

Line 71 of flash.mk is the call for writing the hands .epp to the controller. I did that some time ago with QMK Toolbox, so my firmware does run without any problems anyways, but this error should not happen, i suppose.

Here's the section from flash.mk:

dfu-split-left: $(BUILD_DIR)/$(TARGET).hex cpfirmware check-size
    $(call EXEC_DFU,eeprom-lefthand.eep)

The firmware compiles fine and gets written to the controller and verified successfully, but writing the hands file to the controller fails.

Keyboard Used

avalanche/v4

Link to product page (if applicable)

No response

Operating System

Windows 11

qmk doctor Output

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.5
Ψ QMK home: C:/Files/Repos/QMKFirmware
Ψ Detected Windows 10 (10.0.22631).
Ψ QMK MSYS version: 1.9.0
Ψ Userspace enabled: False
Ψ Git branch: franiac
⚠ 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 12.2.0
Ψ Found avr-gcc version 12.2.0
Ψ Found avrdude version 7.0
Ψ Found dfu-programmer version 1.1.0
Ψ Found dfu-util version 0.11
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2024-02-17 19:20:06 +0000 --  (be44b3305)
Ψ - lib/chibios-contrib: 2024-04-03 20:39:24 +0800 --  (77cb0a4f)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/pico-sdk: 2023-02-12 20:19:37 +0100 --  (a3398d8)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f8)
Ψ QMK is ready to go, but minor problems were found

Is AutoHotKey / Karabiner installed

Other keyboard-related software installed

QMK Toolbox

Additional Context

No response

drashna commented 2 weeks ago

Aside from the error at the end, and the "not blank" part, does it flash correctly?

Franiac commented 2 weeks ago

@drashna Yes, the firmware works perfectly fine after flashing. But my guess is that it only works because I already have flashed the .epp files with QMK Toolbox once. Without that I think it would not work since the 2 parts would not know what's left and right.

Further info: I only habe this problem on Linux (Mint Debian Edition). When I was flashing with Windows (MSYS2) the error did not occur.

Franiac commented 2 weeks ago

Is the "not blank" thing a problem? What does it exactly mean? I don't clear the EEPROM before flashing so that message made sense to me. Am I doing something wrong? Let me know.

sigprof commented 2 weeks ago

The error is returned by the final dfu-programmer atmega32u4 reset command; this just happens on some machines (when the bootloader resets the MCU, it is seen as an USB device disconnect from the computer side, and if it happens before dfu-programmer manages to close the USB device handle, dfu-programmer gets some kind of error and reports it). So you should ignore the error if the previous messages show that the flash process succeeded.

As for the Checking memory from 0x0 to 0x6FFF... Not blank at 0x1. message, in this case it is normal — note that it happens before the flash is erased, so at that moment the flash still contains the previous firmware. The bad case is when that message is seen after Erasing flash... Success — in that case it would mean that the erase did not actually work, and ISP flashing may be needed to recover the MCU from that state.

Franiac commented 2 weeks ago

@sigprof Thanks for your explanation. I understand the second paragraph of your answer. This makes sense, since i don't erase the previous firmware manually.

But where does your dfu-programmer atmega32u4 reset come from. I do not quite understand that. The error points to flash.mk line 71 where the eeprom-lefthand.eep should get flashed. I am not familiar with C build tools at all, so this is probably just a lack of understanding on my side, but I want to understand how you came to the conclusion that the culprit of the error is the closing of the USB handle. Can you elaborate a little more on that, please?

sigprof commented 2 weeks ago

That $(call EXEC_DFU,eeprom-lefthand.eep) expands to a rather long sequence of commands: https://github.com/qmk/qmk_firmware/blob/11daef82e0c710d7bdacc7c78fe21fae864be191/platforms/avr/flash.mk#L25-L53 In this case make receives the exit status of the last command in the sequence, which ends up being dfu-programmer atmega32u4 reset (after substituting things like $(MCU)).

And closing the handle is about the only place where the error can be triggered after the reset operation had been performed successfully (if the error happened anywhere earlier, the reset command would not go through, and the MCU would remain in the bootloader).

Franiac commented 2 weeks ago

Ah, I missed the part that EXEC_DFU is just another function call. Thank you for clarifying!

Since everything has been answered, I am closing this now.