launch_2

[jackpot51]

This adds firmware for launch_2, which takes bits from launch_1 and launch_lite_1.

[leviport]

This is looking great so far. I want to test it a little bit longer next week, but I'm feeling pretty confident about it.

[PeterFalken]

@jackpot51 , @leviport - could you guys give me feedback on this PR on the main QMK repo ?? QMK PR-17478
I'm trying to gain free space by allowing RGB_MATRIX_ANIMATIONs to be disabled in a non intrusive way for system76 keyboards. It seems that the launch_lite and launch_2 wouldn't run into these issues due to the updated MCU, but the solution is generic enough to accommodate them as well.

An example of how it can be used on a keymap file can be found here.

[jackpot51]

@PeterFalken I am on patrrnity leave until Sept 19, if it can wait I'd love to take a look.

[PeterFalken]

@PeterFalken I am on patrrnity leave until Sept 19, if it can wait I'd love to take a look.

Sounds good @jackpot51, enjoy your paternity leave - I will continue exploring other ways to free up space on these keyboards.

[leviport]

I'm now confused on launch_2. It won't flash with make system76/launch_2:default:dfu. If I flash Lite firmware to the same board, make system76/launch_lite_1:default:dfu works fine. I'll keep digging and see if I can find what's different and causing this problem.

[leviport]

Alright, I'm getting closer to knowing what's going on. When I plug in Lite with Esc held, I still see it in lsusb:

$ lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 5986:9102 Acer, Inc BisonCam,NB Pro
Bus 001 Device 039: ID 03eb:2ff9 Atmel Corp. at90usb646/647 DFU bootloader
Bus 001 Device 005: ID 8087:0026 Intel Corp. AX201 Bluetooth
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

However when I put launch_2 into bootloader mode, I do not see it at all:

$ lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 5986:9102 Acer, Inc BisonCam,NB Pro
Bus 001 Device 005: ID 8087:0026 Intel Corp. AX201 Bluetooth
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I'm guessing it has something to do with the USB hub. Will keep digging into it.

[leviport]

Yep, launch_1 still initializes the USB hub when entering bootloader mode, whereas launch_2 does not. Fun stuff.

[leviport]

Looks like the hub actually does initialize and show up in lsusb, but it disappears when bootloader_jump(); is called. If I put a wait_ms(5000); right before that line, the hub appears in lsusb for 5 seconds before disappearing. I'm not sure if this points to this being a problem with the hub or with the bootloader.

[leviport]

Alright, I think I see what's happening. The USB hub chip's RESET pin is mapped to pin A3 on the microcontroller. When the hub is initialized, the controller holds A3 high. I think that when the controller enters bootloader mode, it drops A3 low again, which causes the hub to reset and not reinitialize, which also disconnects the controller.

If this is correct, we'll have to find a way to hold A3 high while the controller is in bootloader mode. I hope this is possible.

[leviport]

Now that I've returned to the office, the USB benchmarks seem about like what I'd expect. I think this firmware is ready to go.

[leviport]

Manufacturer needs firmware, so I'm going to merge this without Engineering review.