qmk / qmk_firmware

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

[Bug] ginkgo65hot keymap got reversed #17307

Closed vuhuucuong closed 2 years ago

vuhuucuong commented 2 years ago

Describe the Bug

Flashed the ginkgo65hot firmware but the keys of the first and last row are reversed, the alphabet keys stopped working completely. (ctrl becomes esc windowsbecomes1, alt becomes 2)

System Information

Keyboard: ginkgo65 hotswap Revision (if applicable): Operating system: windows

Drunktroop commented 2 years ago

Same issue here, even reflashing the default firmware from here resulted in the same situation.

Log from QMK Toolbox looks clean to me

Atmel DFU device connected (libusb0): Atmel Corp. ATmega32U4 (03EB:2FF4:0000)
Attempting to flash, please don't remove device
> dfu-programmer.exe atmega32u4 erase --force
> Erasing flash...  Success
> Checking memory from 0x0 to 0x6FFF...  Empty.
> dfu-programmer.exe atmega32u4 flash --force "Downloads\mokey_ginkgo65hot_default.hex"
> 0%                            100%  Programming 0x4080 bytes...
> [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
> 0%                            100%  Reading 0x7000 bytes...
> [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
> Validating...  Success
> 0x4080 bytes written into 0x7000 bytes memory (57.59%).
> dfu-programmer.exe atmega32u4 reset
Flash complete
USB device connected (HidUsb): (Standard system devices) USB Input Device (6653:3366:0001)
USB device connected (usbccgp): (Standard USB Host Controller) USB Composite Device (6653:3366:0001)
USB device connected (HidUsb): (Standard system devices) USB Input Device (6653:3366:0001)
Atmel DFU device disconnected (libusb0): Atmel Corp. ATmega32U4 (03EB:2FF4:0000)
USB device disconnected (HidUsb): (Standard system devices) USB Input Device (6653:3366:0001)
USB device disconnected (usbccgp): (Standard USB Host Controller) USB Composite Device (6653:3366:0001)
USB device disconnected (HidUsb): (Standard system devices) USB Input Device (6653:3366:0001)
HorrorTroll commented 2 years ago

Same issue here, even reflashing the default firmware from here resulted in the same situation.

Log from QMK Toolbox looks clean to me

Atmel DFU device connected (libusb0): Atmel Corp. ATmega32U4 (03EB:2FF4:0000)
Attempting to flash, please don't remove device
> dfu-programmer.exe atmega32u4 erase --force
> Erasing flash...  Success
> Checking memory from 0x0 to 0x6FFF...  Empty.
> dfu-programmer.exe atmega32u4 flash --force "Downloads\mokey_ginkgo65hot_default.hex"
> 0%                            100%  Programming 0x4080 bytes...
> [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
> 0%                            100%  Reading 0x7000 bytes...
> [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
> Validating...  Success
> 0x4080 bytes written into 0x7000 bytes memory (57.59%).
> dfu-programmer.exe atmega32u4 reset
Flash complete
USB device connected (HidUsb): (Standard system devices) USB Input Device (6653:3366:0001)
USB device connected (usbccgp): (Standard USB Host Controller) USB Composite Device (6653:3366:0001)
USB device connected (HidUsb): (Standard system devices) USB Input Device (6653:3366:0001)
Atmel DFU device disconnected (libusb0): Atmel Corp. ATmega32U4 (03EB:2FF4:0000)
USB device disconnected (HidUsb): (Standard system devices) USB Input Device (6653:3366:0001)
USB device disconnected (usbccgp): (Standard USB Host Controller) USB Composite Device (6653:3366:0001)
USB device disconnected (HidUsb): (Standard system devices) USB Input Device (6653:3366:0001)

U need to clear eeprom before flashing firmware. If not, the old eeprom settings still there.

Drunktroop commented 2 years ago
* QMK Toolbox 0.2.2 (https://qmk.fm/toolbox)
* Supported bootloaders:
*  - ARM DFU (APM32, Kiibohd, STM32, STM32duino) via dfu-util (http://dfu-util.sourceforge.net/)
*  - Atmel/LUFA/QMK DFU via dfu-programmer (http://dfu-programmer.github.io/)
*  - Atmel SAM-BA (Massdrop) via Massdrop Loader (https://github.com/massdrop/mdloader)
*  - BootloadHID (Atmel, PS2AVRGB) via bootloadHID (https://www.obdev.at/products/vusb/bootloadhid.html)
*  - Caterina (Arduino, Pro Micro) via avrdude (http://nongnu.org/avrdude/)
*  - HalfKay (Teensy, Ergodox EZ) via Teensy Loader (https://pjrc.com/teensy/loader_cli.html)
*  - LUFA/QMK HID via hid_bootloader_cli (https://github.com/abcminiuser/lufa)
*  - LUFA Mass Storage
* Supported ISP flashers:
*  - AVRISP (Arduino ISP)
*  - USBasp (AVR ISP)
*  - USBTiny (AVR Pocket)
USB device connected (HidUsb): (Standard system devices) USB Input Device (0853:0141:0001)
USB device connected (usbccgp): (Standard USB Host Controller) USB Composite Device (0853:0141:0001)
USB device connected (HidUsb): (Standard system devices) USB Input Device (0853:0141:0001)
USB device connected (HidUsb): (Standard system devices) USB Input Device (0853:0141:0001)
USB device connected (USBHUB3): (Standard USB HUBs) Generic SuperSpeed USB Hub (05E3:0626:0663)
USB device connected (HidUsb): Logitech (x64) Logitech USB Input Device (046D:C52B:1211)
USB device connected (usbccgp): (Standard USB Host Controller) USB Composite Device (1852:5065:0100)
USB device connected (HidUsb): (Standard system devices) USB Input Device (1852:5065:0100)
USB device connected (HidUsb): (Standard system devices) USB Input Device (0B05:1867:0200)
USB device connected (luxman_audio_iso): LUXMAN LUXMAN DA-06 (1852:5065:0100)
USB device connected (BTHUSB): Realtek Semiconductor Corp. Realtek Bluetooth Adapter (0B05:185C:0110)
USB device connected (HidUsb): (Standard system devices) USB Input Device (046D:C52B:1211)
Atmel DFU device connected (libusb0): Atmel Corp. ATmega32U4 (03EB:2FF4:0000)
USB device connected (HidUsb): (Standard system devices) USB Input Device (046D:C52B:1211)
USB device connected (usbccgp): (Standard USB Host Controller) USB Composite Device (046D:C52B:1211)
USB device connected (USBHUB3): (Standard USB HUBs) Generic USB Hub (05E3:0610:0663)
Attempting to clear EEPROM, please don't remove device
> dfu-programmer.exe atmega32u4 erase --force
> Erasing flash...  Success
> Checking memory from 0x0 to 0x6FFF...  Empty.
> dfu-programmer.exe atmega32u4 flash --force --suppress-validation --eeprom "reset.eep"
> 0%                            100%  Programming 0x80 bytes...
> [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
> 0x80 bytes written into 0x400 bytes memory (12.50%).
Please reflash device with firmware now
EEPROM clear complete
Attempting to flash, please don't remove device
> dfu-programmer.exe atmega32u4 erase --force
> Erasing flash...  Success
> Checking memory from 0x0 to 0x6FFF...  Empty.
> dfu-programmer.exe atmega32u4 flash --force "D:\mokey_ginkgo65hot_default.hex"
> 0%                            100%  Programming 0x4080 bytes...
> [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
> 0%                            100%  Reading 0x7000 bytes...
> [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
> Validating...  Success
> 0x4080 bytes written into 0x7000 bytes memory (57.59%).
> dfu-programmer.exe atmega32u4 reset
Flash complete
USB device connected (HidUsb): (Standard system devices) USB Input Device (6653:3366:0001)
USB device connected (usbccgp): (Standard USB Host Controller) USB Composite Device (6653:3366:0001)
USB device connected (HidUsb): (Standard system devices) USB Input Device (6653:3366:0001)
Atmel DFU device disconnected (libusb0): Atmel Corp. ATmega32U4 (03EB:2FF4:0000)

Full log when it is reflashed right after clearing EEPROM, same result so far

Tried with QMK Toolbox in Win11 & Mac and also qmk flash CLI in Fedora, all seems to behave the same

HorrorTroll commented 2 years ago

huh, weird then

Drunktroop commented 2 years ago

Some extra debug message I could pull from it after switching on the debug flags and recompiled firmware in Linux Pressed Esc first then LCtrl, no output logged when hitting the middle 3 rows afterwards tho

$ qmk console
Looking for devices...
Ψ Console Connected: Mokey ginkgo65hot (6653:3366:1)
Mokey:ginkgo65hot:1: 
Mokey:ginkgo65hot:1: r/c 0123456789ABCDEF
Mokey:ginkgo65hot:1: 00: 0000000000000000
Mokey:ginkgo65hot:1: 01: 0000000000000000
Mokey:ginkgo65hot:1: 02: 0000000000000000
Mokey:ginkgo65hot:1: 03: 0000000000000000
Mokey:ginkgo65hot:1: 04: 1000000000000000
Mokey:ginkgo65hot:1: keyboard_report: 01 00 00 00 00 00 00 00 
Mokey:ginkgo65hot:1: 
Mokey:ginkgo65hot:1: r/c 0123456789ABCDEF
Mokey:ginkgo65hot:1: 00: 0000000000000000
Mokey:ginkgo65hot:1: 01: 0000000000000000
Mokey:ginkgo65hot:1: 02: 0000000000000000
Mokey:ginkgo65hot:1: 03: 0000000000000000
Mokey:ginkgo65hot:1: 04: 0000000000000000
Mokey:ginkgo65hot:1: keyboard_report: 00 00 00 00 00 00 00 00 
Mokey:ginkgo65hot:1: 
Mokey:ginkgo65hot:1: r/c 0123456789ABCDEF
Mokey:ginkgo65hot:1: 00: 1000000000000000
Mokey:ginkgo65hot:1: 01: 0000000000000000
Mokey:ginkgo65hot:1: 02: 0000000000000000
Mokey:ginkgo65hot:1: 03: 0000000000000000
Mokey:ginkgo65hot:1: 04: 0000000000000000
^[Mokey:ginkgo65hot:1: keyboard_report: 00 00 29 00 00 00 00 00 
Mokey:ginkgo65hot:1: 
Mokey:ginkgo65hot:1: r/c 0123456789ABCDEF
Mokey:ginkgo65hot:1: 00: 0000000000000000
Mokey:ginkgo65hot:1: 01: 0000000000000000
Mokey:ginkgo65hot:1: 02: 0000000000000000
Mokey:ginkgo65hot:1: 03: 0000000000000000
Mokey:ginkgo65hot:1: 04: 0000000000000000
Mokey:ginkgo65hot:1: keyboard_report: 00 00 00 00 00 00 00 00 

I don't mind debugging it but I will need some leads in what to look for, first time working on keyboard firmware (or just hardware stuff)

Thanks.

nickdigiulio commented 2 years ago

I had the same issue and I was able to figure it out.

The pins are mis-defined in this file: https://github.com/qmk/qmk_firmware/blob/master/keyboards/mokey/ginkgo65hot/config.h

Lines 29 and 30 should be changed to this:

#define MATRIX_ROW_PINS { B0, B1, B2, B3, F7 }
#define MATRIX_COL_PINS { C7, F6, F5, F4, F1, E6, D0, D1, D2, D3, D5, D4, D6, D7, B4 }
Drunktroop commented 2 years ago

I did the same guesswork yesterday and can confirm I came to the same pin out. I am not sure we got a different PCB or what, since ginkgo65 was shipped to Chinese market quite a bit earlier and I am surprised no one noticed it so far…

fauxpark commented 2 years ago

The pinout for this board declared in config.h is apparently almost exactly the same as the non-hotswap version, but with one less column pin. I'm going to assume it was simply copypasted, and the correct pinout is above.

@runheme thoughts?