TCA8418: TCA8418 Concurrent key presses losing one of the presses

Part Number: TCA8418

I'm having a problem when I press more than one key at a time.  Pressing any 1 key is detected perfectly, always.  If I press 2, or 3, or more keys, if they all occur at the same time (as close as my hands are pressing them concurrently) sometimes 1 or more won't register going down.  The same is true when I release the keys as well.

While my matrix does have 1n4148 diodes, I am able to reduce my design to just enabling 3 keys to even see this behavior, they have taken over completely column 4, 5 and 6.

So to be sure, and disable all the other row/column, I put this:

writeI2C8(FD_PANEL,0x1D,0x00); //SET ROWS PART OF KEYSCAN (R0-R4)
writeI2C8(FD_PANEL,0x1E,0x00); //SET ROWS PART OF KEYSCAN (C0-C3, C7)
writeI2C8(FD_PANEL,0x1F,0x00); //SET ROWS PART OF KEYSCAN (C8-C9)
writeI2C8(FD_PANEL,0x20,0x00); // ROW5 GPIO INTO FIFO

writeI2C8(FD_PANEL,0x21,0x70); // COL456 GPIO INTO FIFO

I've scoped the signals on 4 5 and 6 and they look fantastic.  Not seeing any capacitance droop or excessive ringing.

The only thing I know that is not 100% correct is ROW 6 and 7 are floating because they are not being used in any configuration.  But given the rows are open anyways if no button is down, I didn't think that would cause any problems.

I'm just not sure what else to check.  I have 2 boards built up and both behave exactly the same.

15 Replies

  • When I say take over for 4, 5 and 6, each column goes to a button which has ground on the other side.
  • As a test, I rewrote the code to brute-force scan all inputs (so I am doing what the internal hardware is supposed to do). I set the rows as inputs, set the columns as outputs, drive one column at a time, and I also read the GPIO that I am using direct to a switch connected to ground.

    This works PERFECTLY. No matter how many keys I hit, how fast, I've not lost a single up or down with my polling.

    So at this point, I really don't know what the problem is with the internal keyscan. I hate giving up CPU cycles to do this manual scanning. That said, I just wanted to verify that I didn't see any bounce or lag issues there when hitting fast or multiple keys.
  • In reply to Richard Burnett:

    Hey Richard,

    Can you provide a schematic for me to review? A block diagram of your keypad matrix with the switching diodes would be useful to me as well.

    How long do you press the keys for? Are you doing this by hand or using a function generator and a FET to model a key press in the first post you've made?

    Are you able to place o-scope probes on the rows of the buttons you are pressing? This may help us with debugging.

  • In reply to TRX Bobby:


    This was all done with momentary press chips in circuit.  I've attached the circuit as laid out on the PCB.  SDA/SCL coming from an ARM processor.  100nF between power and ground.  10k pull-up on reset and INT.

    That said, to reduce the complexity to a more simple problem, I just set up the TCA8418 to just listen to the columns with the switches labelled G1, G2 and G3.  This way, only those three were being watched and only those three were told to insert their values into the key buffer.

    Key presses were done by hand.  So if I push down (and held) 2 buttons at the same time, in some cases, one of them would not be detected.

    If I then waited any amount of time then released both at the exact same time, many times one of them will not get detected as leaving the engaged state.  

    It's as if when they both happen at the same time, it cannot see one of them in some cases.

    If the circuit is just watching for changes on those columns assigned to G1, G2 and G3, I am unclear how it could not see the changes.

    (row 5 goes off to another grounded switch and is used as a GPIO, but in the simple case, I ignored it and just used the 3 columns)


  • In reply to Richard Burnett:

    Hey Richard,

    Just to confirm, are you using this device in keypad mode when you are using just the columns?


    EDIT: meaning did you configure the column3-5 to be GPIOs or part of the KP matrix. register 0x1E (KP_GPIO2)

    From your first post it seems the device thinks that column 3-5 are part of the keypad matrix because you have them set as KP with your 0x00h.

  • In reply to TRX Bobby:

    What I did to eliminate any questions about diodes was setup just eveything to gpio but then set those 3 to put their changes in the keyboard buffer to limit the test. In those tests only those 3 inputs are allowed to go to ground when pressing those 3 buttons. That said they behave exactly the same as the scanned matrix. 2 keys on gpio presses at same time by hand, one missed.
  • In reply to Richard Burnett:

    Hey Richard,

    If columns are set to be part of the keypad matrix (through KP_GPIO2 register) then what the columns actually do is go into a GND state when the device is in idle mode. When the device detects a falling edge (on a row input) it enters into scanning mode and then sets all the columns to be HI-Z while it strobes each column to GND for a short amount of time to try to detect which row actually went low.

    These events are recorded in register 0x04 with a FIFO depth of 10 bytes. Now this is for the keypad mode.

    "writeI2C8(FD_PANEL,0x1E,0x00); //SET ROWS PART OF KEYSCAN (C0-C3, C7)"
    If you write 0x00 into this then all the columns from 0 to 7 will be a GPIO and not part of the keypad.

    So you are using the device now as a GPIO where the default setting is an INPUT defined by GPIO_DIR2. The default GPIO_PULL2 register then have your Columns 3-5 as an internal pull up to 100k into Vcc. I believe in this mode the column will then function as a 'row' in active scan mode.

    "writeI2C8(FD_PANEL,0x21,0x70); // COL456 GPIO INTO FIFO"
    This is meant to be a read register which indicates if a column is part of a FIFO event.
    You should be reading the event register to actually read the FIFO (0x04 for event A register).

    Does reading this register until it is empty still show that only one press event has happened?

  • In reply to TRX Bobby:

    Yep, that's what happens when I press 2 keys at the same time, but not every time, it's intermittent (or likely I am not hitting them at exactly the same time every time since I am just pushing with two fingers).

    If I press each of the buttons by themselves and release, I see in 0x04 both down and up as I read them out.  If I even do say A down B down A up B up slowly I see them all.  If I do just A as fast as I can possibly hit the button, I never miss a down and up sequence from the FIFO.

    However, if I press them down at the same time (as exact as I can) and I look what comes out of the FIFO, I get one of them down and not the other.  Not ever time, let's say like 50% of the time it misses one.

    I keep pulling from the FIFO until it returns 0.

    I even just kept pulling from the FIFO and just printing out when it was not zero,  just to see if it was in there, but somehow was after a zero returned.

    It's like somehow, when I hit both buttons at the same time, one is masking the other.  (Let's forget about keyscan mode for now and just focus on those 3 as GPIO that I told it record their changes in the FIFO).

    When I hooked up a scope to the switching to see what the bounce looked like, very clean edges.  

    Just doesn't seem like a lot of other settings to try changing.


  • In reply to Richard Burnett:

    Hey Richard,

    I ordered some EVMs for this device to be shipped to me. I will try to see if I can reproduce what you are seeing as well.

    I do have quite a bit to do this week so I may not be able to get the EVM set up immediately when it does arrive but I will try (likely this Friday).

    One thing you can try doing is adding an external pull up resistor on your columns (about 10k or so) to Vcc and repeating your multi button press test. Let me know if adding the resistors changes the results.



  • In reply to TRX Bobby:

    Hello Bobby,

    For columns C4, C5 and C6 I tied a 12k (all I had) resistor to VCC (3.3V) and then reran the test on just those 3 buttons (each column had it's own 12k tied to VCC).  No change in performance.  Pressing multiple buttons still ends up causing events to be missed in the FIFO.