The problems are almost entirely isolated to the top two rows of the Navigation and Keypad cluster, and the vertical columns below PRINT and KP_DIVIDE. That makes it seem like a hardware problem, although I cannot think of a combination of shorts, opens, and bad diodes that would explain this behavior.
For example a keypress at matrix location 3,20 (KP_7) should do the following:
- Column pin E0 goes high.
- Switch and diode at 3,20 allow row pin D4 to go high,
- A scan of row pin D4 shows high, resulting in keypress and release events for KP_7
But in addition...
- C2/B1 shows high, resulting in keypress and release events for 0 (or ")" if I test while SHIFT is pressed.)
NOTE: I just tested to verify that the map for the keypad has the keypad zero key outputting KP_0. It does.
- D6/D2 shows high, resulting in keypress and release events for KP_2.
- D6/D3 shows high, resulting in keypress and release events for KP_5.
- D6/D4 shows high, resulting in keypress and release events for KP_8.
That is just one example, and I am trying to work out a combination of bad diodes, shorts, and opens that would result in those scan results. I accept that the high on E0 could escape through a bad diode, and even that the entire column under KP_DIVIDE is hosed thereby, but how does the 0) key get involved?
I'll bring my test PCB and multimeter home with me in case you have a brilliant flash or a question. The current .DAT and .HEX files are attached.
Thanks as always!
- Ron | samwisekoi
This is quite vexing. I can only come up with three ideas.
First, that you have some kind of crazy hardware problem. However this board is not very complicated at all. We can assume the Teensy is all good, so I don't think this is the problem.
Second, that you have the strobe_cols and strobe_low configured wrong. This could leave pins floating which makes it conceivable that nearby rows affect each other through inductive coupling. However, since the entire left half of your board works correctly, this is probably not the problem. Still, there are only four possibilities, watch your PMs for some test builds.
NOTE the series of events you described as "pin goes high" does not happen with the gh122 config file currently in Github. It has strobe_cols = False and strobe_low = True. That means it selects rows then reads the columns, and it selects the rows by bringing it down to 0, with all non-selected rows set to 1. Does your hardware still make sense using that logic? If not, we will have to change it.
Third, that the software is overrunning its schedule and not handling it gracefully. I had this idea because all your problems are localized to the far end of the board. For a matrix that large, it's basically guaranteed to overrun the schedule, but it shouldn't lead to problems like this. I'll review that part of the code, maybe it was damaged in the rewrite.
So thats what I have so far. Nothing like a good puzzle, right?
One final thing, if 4,16 doesn't exist, what is the correct location of ANSI enter?