Flashing Launch Heavy with keyboard-configurator 1.3.6 fails with 'dfu-programmer: no device present'

[hendersj]

Using the 1.3.6 AppImage, and following the procedure at https://support.system76.com/articles/launch_2-firmware-update/ on openSUSE Tumbleweed (20230603) results in the following output:

[jhenderson@TheEarth ~/Downloads]$ ./keyboard-configurator-1.3.6-x86_64.AppImage --launch-test
Gtk-Message: 13:28:41.219: Failed to load module "canberra-gtk-module"
Gtk-Message: 13:28:41.260: Failed to load module "canberra-gtk-module"
Gtk-Message: 13:28:41.261: Failed to load module "canberra-gtk-module"
[INFO ] Not running as root, spawning daemon with pkexec
[ERROR] Failed to access LPC EC: Io(Custom { kind: NotFound, error: "Failed to find System76 ACPI device" })
[INFO ] Adding USB HID EC at "/dev/hidraw1"
[INFO ] loading
[INFO ] display loader called with Keyboard(s) detected. Loading...
[ERROR] failed to get matrix: Hid(HidApiErrorEmpty)
dfu-programmer: no device present.
dfu-programmer: no device present.

What can I do to further diagnose this issue so I can update my keyboard (the standard keyboard update with fwupdmgr fails, which is why I'm using this method).

[leviport]

After plugging in with the Esc key held, do you see a Atmel Corp. at90usb646/647 DFU bootloader device in lsusb ?

[hendersj]

I do - the output from lsusb -v -d 03eb:2ff9 is:

Bus 001 Device 038: ID 03eb:2ff9 Atmel Corp. at90usb646/647 DFU bootloader
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        32
  idVendor           0x03eb Atmel Corp.
  idProduct          0x2ff9 at90usb646/647 DFU bootloader
  bcdDevice            0.00
  iManufacturer           1 System76
  iProduct                2 system76/launch_2 Bootloader
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x001b
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       254 Application Specific Interface
      bInterfaceSubClass      1 Device Firmware Update
      bInterfaceProtocol      2 
      iInterface              0 
      Device Firmware Upgrade Interface Descriptor:
        bLength                             9
        bDescriptorType                    33
        bmAttributes                        3
          Will Not Detach
          Manifestation Intolerant
          Upload Supported
          Download Supported
        wDetachTimeout                      0 milliseconds
        wTransferSize                    3072 bytes
        bcdDFUVersion                   1.10
Device Status:     0x0000
  (Bus Powered)

Should it be identifying it as a launch 2 bootloader rather than a launch heavy 1 bootloader? (The keyboard is a Launch Heavy).

[leviport]

They should use the same bootloader, so that should be fine. Launch_heavy_1 uses a launch_2 PCB, just with slightly different firmware so that it supports the Heavy daughterboard (the two separate boards can be seen in tech-docs for Heavy).

I'm not sure why dfu-programmer isn't finding it when it's in bootloader mode though. I'll have to investigate a bit and come back.

[hendersj]

Thanks - appreciate it. Doing this process, should I be seeing the letters "UNLOCKED" light up, or is that just when unlocking the keyboard for the normal flash process? (Doing it this way, the keyboard stays dark the entire time)

[leviport]

"Unlocked" mode is for updating via fwupd, which would be the normal way of updating, but there was an issue with entering bootloader mode from "unlocked" mode on some keyboards. That's why this upgrade path is so atypical this time around, but this should be the last time such a workaround is necessary.

[hendersj]

That's what I thought - thanks for the additional info.

[hendersj]

Wanted to check back in and see if there was any additional information I could provide.

[leviport]

Sorry, I forgot to follow up here. I did have an idea though. Since the bootloader does appear, another option is to flash the firmware directly from our QMK fork: https://github.com/system76/qmk_firmware/blob/master/keyboards/system76/launch_heavy_1/README.md

[hendersj]

Thanks - just to make sure I understand, it might work to follow the DFU procedure here, and then re-flash with the regular method, or does this method get me the version of the firmware that's officially released?

[leviport]

If you check out the 0.7.103_backup_DO_NOT_DELETE branch, it'll get you what's released currently. But running what's in master is also fine, and it'll be what's released pretty soon. We just wanted to make sure we fixed the update process before doing another release.

[hendersj]

Thanks - seem to be getting closer. Because I'm not on a recognized OS, I'm having to use the docker build process, but when I check the branch out, the build fails, saying:

$ util/docker_build.sh system76/launch_heavy_1:default
QMK Firmware 0.12.20
ERROR: Can not run bin/qmk!

 Please run util/qmk_install.sh to install all the dependencies QMK requires.

make: *** [Makefile:505: system76/launch_heavy_1:default] Error 1

I was able to build the main branch, but the dfu flashing won't recognize the keyboard is in bootloader mode - I'm guessing because the Docker container doesn't have visibility to the USB devices.

Is there documentation for what the command-line would be for dfu-programmer?

As an alternative, I can boot up a VMware virtual machine in whatever OS I need, and I did notice that with the keyboard operating as a keyboard, I can't see it in the USB device list (which makes sense), but in bootloader mode, I do see it and can attach it specifically to the VM - is flashing via a VM something that's been tested (or is feasible)? Or does the process reboot the keyboard multiple times, which might leave it disconnected from the VM at a critical moment?

[leviport]

It should only reboot once flashing is complete.

[hendersj]

Cool, I'll give that a try and report back how it went.

ETA: Happy to report that that that worked - did the build and flash from within a Pop!_OS VM, and once it flashed with the 0.7.103 firmware, I was able to use fwupdmgr to update to 0.7.104 firmware that's now available.

Thanks for all the help!