The GH60 keyboard is not functioning after compiling.
NAAAAAP opened this issue · 12 comments
I'm a beginner, and I encountered a problem while compiling GH60. After flashing the compiled GH60 hex file, I shorted D4 and other pins, but none of the keys are registering. Upon further debugging, I realized that none of the functions in the matrix.c file in the GH60 folder are being triggered.I don't understand why this is happening.Please help me.T T
The operating system is Windows.
The AVR GCC version is 7.3.
what is actually you hardware? Genuine GH60 pcb or anything?
which pins did you try as 'other pins'?
Thank you for your response. I am using the Pro Micro ATmega32u4 5V/16MHz (similar to this one: https://github.com/sparkfun/Pro_Micro). After compiling and flashing the gh60_lufa.hex firmware onto the board, I tried to use pin D4 (which is the 7th pin from the left on the board, is that correct?) and shorted it to all the other pins on the board for testing, but it seems that the key presses are not being triggered.
Note that pin names on Pro Micro is different from ones in firmware codes.
Yes, D4 pin on Pro Micro happen to be identical to PD4(or D4) in firmware. But other pins are not.
Check this for real pin names(PD*/PB*/PF*) that used in codes. https://github.com/tmk/tmk_keyboard/wiki/Pro-Micro#pinout
You will see '6' when making short circuit between PD4 and PD0. PD0 is marked '3' on Pro Micro and placed next to PD4.
I confirmed this on my Pro Micro, its firmware was built with avr-gcc 7.3.0 on Linux.
$ avr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.7.0_1796) 7.3.0
Copyright (C) 2017 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.
I got avr-gcc installed from this.
https://www.microchip.com/en-us/tools-resources/develop/microchip-studio/gcc-compilers
I have reviewed the documentation you provided, and I believe my understanding of the pin definitions is correct. I have shorted the PD4 and PD0 pins as you mentioned, but it did not trigger any buttons (the same goes for D4 and other pins). I haven't made any modifications to the code and successfully compiled it (at least that's what the terminal indicated). I'm not sure if there could be other factors (system-related or otherwise) involved during this process. Is it possible for me to obtain a compiled gh60_lufa.hex file from you? I would like to flash it onto the board and see if there are any differences.
This is the file I have compiled
Tried your hex file and got same result, '6' is registered on Linux and Windows as expected.
This is my hex file and almost same. I think you built firmware properly, so your hardware setup is a cause.
gh60_lufa.hex.zip
My pro micro pins are all open, no components is attached, for FYI.
How did you flash the hex file?
I'm using avrdude like below, FYI.
avrdude -patmega32u4 -cavr109 -b57600 -Uflash:w:/home/noname/Downloads/gh60_lufa.hex -P/dev/ttyACM0
You can use debug console(hid_listen) to check debug prints from the converter.
https://github.com/tmk/tmk_keyboard/wiki#debug-console
you should see a message like below when you plug in.
Waiting for new device:.........
Listening:
TMK:f25b51/LUFA:d6a7df
bootmagic scan: ... done.
USB configured.
Loop start.
According to your instructions, I used hid_listen for debugging and use xprintf() to show values on debug console in the host.c file. The display in hid_listen is as shown in the following image.
host.c
/* send report */
void host_keyboard_send(report_keyboard_t *report)
{
if (!driver)
return;
(*driver->send_keyboard)(report);
xprintf("keyboard: ");
for (uint8_t i = 0; i < KEYBOARD_REPORT_SIZE; i++)
{
xprintf("key:%02X ", report->raw[i]);
}
xprintf("\n");
}
According to the image, the keycode is displayed, but no key presses are being sent to the computer.
(*driver->send_keyboard)(report);Is this the final invocation for sending key to the computer?
Please tell me what I can do next to debug.
Share all codes you changed for next time so that I can know what it means in debug prints easily.
I guess you connected PD0 and PDB and you get a key pressed at [row=0, column=13]. The key is Back Space(0x2A). It is correct and what we expect, so far ...
Ah, I found that NKRO mode doesn't work properly. The firmware depends on eeprom contents to select the mode but it has not worked for years after some changes. My Pro Micro seemed to have old eeprom content, and it happened to work somehow.
This was just fixed, try the latest source code in the github repository. You may have to wipe out eeprom if this does not solve the problem.
Hasu, long time no see. Thank you for your repair, but it still couldn't solve the problem. Finally, I found that when I turned BOOTMAGIC_ENABLE = yes off, the firmware started working.
I think your eeprom was messed up unfortunately and includes incorrect state(for NKRO mode).
Yes, disabling boot magic is a right move.
Another solution is to erase eeprom, or overwrite all bytes of eeprom with FFh.