Rev6. Keyboard Ghosting - center key replicating full row

[rjaquez]

The 5,T,G,SPACE keys are replicating the full row they are on. In sequence.

So if I tap the 5, I get all the keys in that row in order, and so on.
This includes modifiers. So if I tap the t, which has menu, it acts like a macro key.

I have tried a few things, and it still seems to be happening:

• new key map
• reset via menu
• firmware upgrade

EDIT:
I opened up the device to see I could notice anything perhaps shorting, or some issue. But nothing is immediately apparent.

[unkyulee]

This can happen when rev.5 firmware gets in to hardware of rev.6 and vice versa.

Can you make sure if the firmware revision corresponds to the hardware, please?

[rjaquez]

I did try a firmware upgrade earlier, and that did not solve it.

I did just do it again - this file: firmware_rev_6.bin

correct?

it did upgrade and when I enter the menu I see: 1.0.16.r3 REV.6
But the problem is still happening.

EDIT: The problem does persist with no keyboard.json and with a default keyboard.json

[rjaquez]

Well.. I tried to use VScode and PlatformIO from a mac to see if I could flash the firmware directly. I also got a new sd card... and I've made the problem worse 😄

First, there was an error when I selected upload, here are the last few lines of that message:

Configuring upload protocol...
AVAILABLE: cmsis-dap, esp-bridge, esp-builtin, esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa
CURRENT: upload_protocol = esptool
Looking for upload port...
Auto-detected: /dev/cu.usbmodem58960409011
Uploading .pio/build/esp32s3-keyboard/firmware.bin
esptool.py v4.5.1
Serial port /dev/cu.usbmodem58960409011
Connecting....
Chip is ESP32-S3 (revision v0.2)
Features: WiFi, BLE
Crystal is 40MHz
MAC: f0:9e:9e:11:3f:e0
Uploading stub...

A fatal error occurred: Failed to write to target RAM (result was 01070000: Operation timed out)
*** [upload] Error 2
============== [FAILED] Took 7.14 seconds ==============

Environment       Status    Duration
----------------  --------  ------------
esp32s3-usbhost   FAILED    00:00:07.225
esp32s3-keyboard  FAILED    00:00:07.140
======== 2 failed, 0 succeeded in 00:00:14.365 ========

However, even with that error now the first row seems to be doing the same thing. So the first row and the 6th row are acting like macro keys. and printing out the full line or fully executing that line. So if the line has SHIFT at the beginning it prints all the shift characters, if it has ALT, same thing - the menu line goes to the menu but then enters a sub menu based on the characters on that line. Sounds confusing. I can take a video, but perhaps you know what it is.

I did try putting the firmware_rev_6.bin on the new sd card after, and allowed it to upgrade again, but the issue still persists - line 1 and line 6.

My next thought was to try this from a windows machine perhaps? Let me know if you have any ideas. Thanks for all the help!

[unkyulee]

Hmm.. sounds like it is a hardware issues.
Vscode failed to upload the firmware so, that didn't have any impact.

I think keyboard connector needs to be inspected.

When you remove the keycaps you can see 8 screws. Unscrew all of them.

Then you should be able to pull the keyboard plate out from the device.

Peel off the keyboard plate from the PCB and you should see the 16 wire holes solders. Is there any shorts or wandering wires touching each other?

[rjaquez]

I was able to check, nothing seems wrong with the keyboard solders. No wandering wires, or shorts.

I did try vscode on my windows machine, to try and reflash - that actually did work.
All Success, no failures or errors. But now I am getting a white screen.

[rjaquez]

I am able to monitor the port, and I'm seeing this in a loop:

Rebooting...
@�␀���J9�9f�
�����J␌�+&�S␅RDevice Started. Baud rate: 9600
[279] SPIFFS mount succeeded!
[279] SD Device CS: 9
[300] SD Device Initialized
[300] SD Card detected
[309] Loading config ...
[309] App Status loaded
[309] Opening config.json file
[436] Deserializing config.json file
[437] Loading app status config
[437] Config loaded successfully!
[559] Total heap: 322756
[559] Free heap: 292012
[559] Total PSRAM: 8386247
[559] Free PSRAM: 8359067
[560] Loading keyboard.json from SD
[703] main loaded
[703] main-shift loaded
[703] alt loaded
[704] alt-shift loaded
[705] Keypad initialized
[705] DISPLAY SETUP
Guru Meditation Error: Core  1 panic'ed (StoreProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x4200deaf  PS      : 0x00060c30  A0      : 0x8200dfa0  A1      : 0x3fcebb80  
A2      : 0x00000010  A3      : 0x00000000  A4      : 0x60004000  A5      : 0x0000000b  
A6      : 0x000000ff  A7      : 0x00000008  A8      : 0x08000000  A9      : 0x3fcebb50  
A10     : 0x3fca2f50  A11     : 0x00000001  A12     : 0xffffffff  A13     : 0x00000008  
A14     : 0x00000000  A15     : 0x00000004  SAR     : 0x00000010  EXCCAUSE: 0x0000001d  
EXCVADDR: 0x00000010  LBEG    : 0x420196e8  LEND    : 0x4201974c  LCOUNT  : 0x00000000  


Backtrace: 0x4200deac:0x3fcebb80 0x4200df9d:0x3fcebbb0 0x4200dfa8:0x3fcebbd0 0x4200a710:0x3fcebbf0 0x4200c65a:0x3fcebc20 0x4201ac36:0x3fcebc50




ELF file SHA256: 9b91248d3305f459

E (1470) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0
Rebooting...

[rjaquez]

So, I started looking through the other bug reports and came across this message:

I've figured this out, and it can be closed as it seems that I'm the only one experiencing this. The behaviour is caused by an issue with the TFT library, and the solution is here: Bodmer/TFT_eSPI#3304

dbtronics commented on May 6
For anyone still tackling with this issue. Change your ESP32 board package back to 2.0.14. As that is the package compatible with this TFT_eSPI and will solve the infinite reset loop problem.

Tested, and now working. I changed line 2 in platformio.ini to this:

platform = espressif32 @ 6.5.0

Source: #16 (comment)

and this message:

Thanks for reporting the problem and also recording the solution. I have applied to the project configuration as you have specified.

I think leaving the issues open is fine. If in any case when someone encounters similar problem, it can be helpful.

I then checked my platform.ini and that config change was not there. My source is old - it is from the releases page: 1.0.16.zip

So I deleted all that, I've cloned the repository and I can see that platform.ini has that update. It is compiling and uploading right now. Takes about 10 minutes.

Ideally this at least brings be back to the firmware working - and maybe the keyboard fixed, but even if the keyboard is not fixed, at least I'm back to troubleshooting the original problem.

[rjaquez]

Ok. I was able to flash the firmware successfully using the latest source from git.
It might be good to reference this in the Flashing the firmware for the first time of the build guide

I can write a draft if you like. Basically it's probably just formatting that section a bit differently, maybe as bullets? and perhaps adding some screenshots for PlatformIO in VSCode.

I'm back to troubleshooting the keyboard. The first key and sixth key of each row are still printing out the full row.
I'm going to take it apart again and use my multimeter to see if I have any shorts.

[rjaquez]

After a bunch of research, I realized that the issue i described is called ghosting. I renamed this issue accordingly.

I have been able to successfully reload the firmware via the UART port from a windows machine consistently, no issues. I did find that I had to specify the port in VSCode, and not let PlatformIO auto pick.

I was also able to rule out software as a culprit. I changed some code in keypad.cpp to log the key presses, and do a few different things, and the issue definitely persisted.

I then looked at the build guide and identified which pins might be the ones causing issues - I used my multimeter first on the esp board itself, with a plan to do the same on the keypad pins. I was able to detect two pins shorting (39/40). Poking around with my multimeter was enough to separate them and clear the issue.

If this happens again, I will probably just resolder those connections. Maybe even change them to quick disconnects.