Ghosting on some keys when using keypad.KeyMatrix.

[SeanCline]

CircuitPython version

Adafruit CircuitPython 8.0.0 Beta 6.

Code/REPL

https://github.com/SeanCline/RabidKeyboard/blob/main/firmware/code.py

Behavior

I designed and built a keyboard using the KMK firmware. After using it for a few months, I noticed some weird ghosting on two key combinations.

• When pressing LeftGui and LeftShift, LeftControl sees a phantom press.
• When pressing A and Tab, CapsLock sees a phantom press.

Description

Looking at the matrix schematic, you can see a pattern here. Enabling KMK's logging, this phantom keypress seems to happen on every other scan of the matrix. Very strange!

Normally, when ghosting is involved, you'd suspect the diodes. But, since only two keys are required to trigger the phantom press, I cannot think of any way a diode could be to blame.

Additional information

So, I started reviewing the KeyMatrix scan logic and I noticed that it scans as fast as possible. At the end of each scan, it asserts the resting state of the row and switches to a pulled input before moving onto the next row. This logic was added by @dhalbert a couple years ago.

I suspect this final bit of logic important, but is happening too fast to discharge any stray capacitance and/or trace inductance of a bigger key matrix. When the next row is scanned, the column input still briefly sees the previous row's value. This makes some sense because the two ghosted keys are on the furthest column from the microcontroller.

I have a solution for my keyboard. After scanning each row, I check the columns a few times to make sure they've settled to their resting value. See this diff: main...SeanCline:circuitpython:main
Perhaps somebody might have a better solution, but I think stray capacitance/trace inductance is to blame, and hopefully it's possible to make the matrix scanner more resilient to it.

[dhalbert]

The explanation for that code is here: #5031. I don't remember the details now, but I thought it would fix the problem because of the active driving. Apparently this is not always the case.

I'm a little confused by your suggested change, because it waits for all the keys to be unpressed, according to the comments. But that would stall the scanning, (wouldn't it?), for the time you held down a key.

[SeanCline]

Wow, that was a quick response! And #5031 sounds like my exact problem.

I thought it would fix the problem because of the active driving.

The active driving does look like a good approach. It's possible my keyboard is just particularly bad when it comes to parasitic capacitance and inductance and it takes a bit longer to drain them via active driving.

I'm a little confused by your suggested change, because it waits for all the keys to be unpressed, according to the comments. But that would stall the scanning, (wouldn't it?), for the time you held down a key.

It does the wait while all of the rows are pulled inputs, so a key being pressed does not matter at that moment in time as no rows are driven. If a column reads a pressed key at that point, then something is either wired wrong, or it's been a victim of the electrical properties of the board.

As long as my understanding of the problem is correct, a combination of the active driving approach and a small delay sounds better than my approach of waiting for the columns to settle down. I went straight to this approach rather than a delay because it let me confirm that a column showed a pressed key at a time when no row was driven.

[dhalbert]

You can use mp_hal_delay_us() to delay for microsecond-resolution intervals. This is a busy-wait loop, so don't do it for long.

I see you are using an RP2040. I was going to suggest that it might help to set the drive strength higher, but we have already set the drive strength for DigitalInOut's to 12 ma.

[SeanCline]

Inserting a mp_hal_delay_us(1); between asserting the row to its resting value, and turning on the pull resistor, also solves the problem for me.

I'm not really sure where to go from here. Pretty much anything solves the issue on my keyboard. It's a matter of finding a solution that's good enough to upstream for all keyboards, and hopefully puts the issue to bed once and for all. Any ideas?

[dhalbert]

Inserting a mp_hal_delay_us(1); between asserting the row to its resting value, and turning on the pull resistor, also solves the problem for me.

I'm certainly willing to add that. One other thing to try: in place of the mp_hal_delay_us(1), add asm volatile(""); That will prevent certain compiler optimizations, which might be affecting that.

[SeanCline]

I hadn't even considered compiler optimizations. I gave your compiler fence a try to no avail -- it ghosts just like a stock CircuitPython build.

I don't know much about ARM but I for good measure I also tried a hardware fence __atomic_thread_fence(__ATOMIC_SEQ_CST); which compiles to a dmb instruction. This also behaves exactly the same.

Man, sleeps/delays feel dirty to me. I was really hoping to come up with a better solution.

[SeanCline]

I've been running my keyboard for more than a year now with an mp_hal_delay_us(1); to allow more time for the pin to be pulled to its resting state.

In the absence of a better solution, do you think this is acceptable to merge?

[dhalbert]

In the absence of a better solution, do you think this is acceptable to merge?

I think this is fine. It's probably due to a weaker pull. One microsecond is very small. Go ahead and make a pull request.

[SeanCline]

Excellent! I've created PR #9665.

[dhalbert]

Closed by #9665.