Issues with X, V, U and O

[mkw432]

I have two builds going and can't identify any soldering defects but on both boards the X, V, U and O keys (in standard QWERTY layout) don't work. I'm guessing the mirrored problem keys are due to the Japanes matrix layout. Any suggestions for where I should have a closer look?

[tompi]

Thats strange!

Just to rule out fw issues: do these keys work if you Flash the miryoku uf2 file?

If same problem there, could you post some high res images of both sides and halves, preferably with keycaps off...

[tompi]

Oh, and the mirroring is probably because of this row is mirrored over the rj45.

PERHAPS its worth trying a different cable, not sure what effect a crossover cable will have on the matrix...

Anyway, test the precompiled uf2 file first!

[mkw432]

Thanks so much for the quick response (and let me know if easier/better to discuss this elsewhere)!

I'm beginning to suspect it's a problem with my soldering or (less likely) the PCB from JCPCB. After cleaning off some flux mess with rubbing alcohol and a close inspection, one of the boards worked briefly and now is ghosting a bunch of keypresses on certain keys (e.g. QWERTY "I" hits Y, I, P and Z, C, B. Could it be my cheap Ali Express diodes (probably using a handful from two different orders)? Sorry meant to say that I've tried a few different cables with no change (the left half also shows the issue with the cable unplugged).

I'll upload pics of the top half in just a few after I take off the keycaps. Thanks again!

[mkw432]

Sorry - also meant to add that I tried the Miryoku .uf2 and also compiled/flashed the default QWERTY firmware but the broken keys didn't work with those either. Likewise couldn't get a response by jumping the pins on the switches that weren't working. I do have a multimeter I could use to test for continuity but the unique matrix (which is super cool BTW) is beyond my ability to follow and diagnose by myself. Any guidance there on what I should check (or a doc you could point me to that might help me figure out how to test)?

I did use kapton tape under the RJ45 connectors on this second build (first build was just masking tape) but that didn't seem to make a difference. I also have a bunch of SMD 1N4148W-TP diodes I could try to swap in if you think that might help. Thanks again!

[tompi]

Your soldering looks very neat, I dont think thats the issue.

Could you use a multimeter to verify that each of the pins is the problem switch connects to exactly one pin of the rj45 connector?

Make sure to switch polarity if you think you find one missing(you might be checking against the diode...).

I actually got a pcb with a broken trace once from jlcpcb, but i thought it was very rare... but thinking about it, you said it started working after cleaning...

Oh,and the "ghosting" is probably just the encoder not de-tenting properly. It happens. Just twist it slightly and see if it stops.

[mkw432]

With the positive probe on the top switch pin, I get a connectivity beep on exactly one RJ45 pin for both of the broken switches on the right half top row (U and O). The bottom switch pins for U and O show about 0.7 MΩ of resistance on exactly on RJ45 pin each (but don't beep). I noticed that at least one of the working switch pins in the middle row (maybe others too) shows various resistance numbers on multiple RJ45 pins. Could that be contributing to the issue? Do the left half switches connect to the RJ45 as well - if so, I'll test those too.

I also wondered if maybe I have a solder bridge between the MCU holes and the bigger holes for the thick "legs" of the encoder. Might be either a bridge on the right half (e.g. between the actual encoder leg and the unused MCU hole) or on the left half (e.g. between the actual MCU socket pin and the unused encoder leg hole). Could that contribute to the issues I'm seeing?

[tompi]

Ok. Should be pretty easy to test for solder bridge? That might have strange consequences. Different resistances should not matter, unless you Get below what the rp2040 will register as a signal...

Could you also check that each of the switch pins Are connected to exactly one mcu pin?

[mkw432]

Yep, no problem. Is it OK to test the left half without the RJ45 plugged in or do I need everything connected to test correctly? Thanks so much - super helpful.

[tompi]

I think its good to just focus on left, sure.

If you got a bridge, i guess there might be continuity between the pin and ground?

[mkw432]

There is continuity between most of the "bottom" pins and ground! The few that don't have it are working. Does that mean I've got a bridge somewhere?

[tompi]

Yep, that should be the problem. But most? Seems strange that there should be many?

[mkw432]

Sorry should have clarified that the bottom pin on most of my switches has connectivity with ground on the RP-2040. But a couple of them don't and the ones that don't are among the keys that are working just fine (but many of the others that work fine also show connectivity to ground on that bottom switch pin).

[mkw432]

Could it be a bad batch of RP-2040s from the AE seller I bought from?

[tompi]

Highly doubt that.

Did you order pcbs from the "release" gerber, or did you make the gerber yourself with kicad?

I had to break out my own multimeter here and test on an empty pcb, there is definitely no continuity between ground and any other traces. Could you check that on your remaining empty pcb to rule out a bad batch?

If thats ok its probably a soldering issue.

Can you tell me exactly which pins are connected to ground? If its the same pins as the encoder is using, you might examine that: pin 1-4, starting from upper right outside corner of left side.

[mkw432]

Hmm couldn't find any continuity with ground between any of the switches/diodes on the empty PCB. For the boards I built, the ground connection seems pretty weak and only shows up with the red/positive probe on GND and the black/negative probe on the switch pin or near side of the diode. I have to use the continuity function - the connection seems too weak to register on the multimeter's lowest resistance mode. But weirdly I have a completely functional Ocreeb macropad I build with a similar MCU (KB2040) that shows the same behavior - there is a weak connection between GND on the MCU with half the switch pins and the other half have continuity with the probe on the near side of the diode. Both of my Cheapinos and the Ocreeb all show a weak connection between the GND pin and each of the other MCU pins as long as I put the + probe on ground and use continuity mode. Is that not normal?

[tompi]

Im not really sure... Could be the resistance of the diode? What do you measure them to? (in both directions)

Could you do one more test. If you short pin 2 and 5 on rightmost(outer) line of the rp2040, starting at the top. you should get "x" and "c"

I assume you attempted to short the switch both "before" and "after" the diode?

Still exactly same behaviour on the two left halves?

You said it started working shortly at one point?

[mkw432]

Shorting the pins marked 2 and 5 gives me "A" and the middle key on the left thumb cluster (which I assigned to layer tap with space on tap). I think X and C are pins marked 1 and 4 (which are the second and fifth pins so that's probably what you mean)? But shorting those only gives me C (which is a key that's working) but not X (which is a key that's not currently working). Does that mean it's likely a firmware/software problem?

[mkw432]

So it looks like on this particular board, one of the two keys connected to the GP4 pin isn't working. That's X (GP4, GP1), V (GP4, GP0), Left key on left Thumbcluster (GP4, GP2), Left key on right thumbcluster (GP4, GP27), U (GP4, GP29) and O (GP4, GP28). Weirdly on the other board, it's now showing a completely different issue where the keys connected to GP6 (QWERT, NM,.?) and the rightmost keys on both thumbclusters are either doing nothing or going bonkers with outputting a bunch of keys in the list.

[tompi]

Yes, this indicates a firmware issue. Could you try the same with the miryoku uf2 file: shorting gp1 and gp4?

Make sure that its flashed, that you dont still have qwerrty.

The issue on the other board sounds like a short somewhere...

[mkw432]

Same result with the miryoku uf2. Shorting other pairs of pins gets me two keys output but that particular pair only does one. Oh and I just used the release gerber - don't have any kicad ability to make my own. I think I'll fiddle around and see if I can flash some circuit python or something to help me trace the GPIO pins and inputs, etc. Thanks for all of your help!

[tompi]

Sorry, but running out of ideal:(

There is one pretty nifty debugging you could try, if you comment in the debugging statements on Line 31 to 34 here: https://github.com/tompi/qmk_firmware/blob/cheapino/keyboards/cheapino/cheapino.c

And then Flash the fw, you will Get a lot of debugging when running "qmk console"

Im curious what matrix is registered when shorting gp1 and gp4, it really doesnt make sense that there should only be one key registered. The problems from using the japanese matrix Are always that too many keys Are registering...(ghosting)

[mkw432]

Hmmm - I commented out those lines and both "qmk console" and hid_listen can now connect to the Cheapino but no debug output comes through. I was trying to see if I could add a print statement to process_record_user() like the example in the QMK debug FAQ but I couldn't find a processrecord* function in your QMK folder. Probably due to the default keymaps using the QMK configurator .json files rather than the old fashioned keymap.c I'm used to.

[tompi]

You meant commented in, right?

This is very interesting, you Get some debug info? Like the name etc when plugging in?

What command do you use to compile/flash?

I was also thinking, shorting gp1 and gp4 giving only 1 key makes no sense. Did you socket the controller? If so could you try shorting with it out of the keyboard? If its still faulty, with another usb cable and possibly on another pc/tablet/phone

[mkw432]

Yep, sorry - I meant commented in those lines by removing the pound sign. The debug info just shows the name of the board and then listening but nothing else. QMK Toolbox actually shows your name. Weirdly if I assign the QMK debug toggle to the first key (instead of KC.Q) it will show up as debug on or off when tapped but otherwise there's no debug output at all.

[mkw432]

I've just been using "flash -kb 0cheapino -km default" (manually saved your Cheapino directory at the top of my QMK keyboards folder by appending the zero). Finishes compiling without any errors and then waits for me to enter DFU by hitting Boot + Reset on the RP2040-zero and finally flashes without any errors.

[mkw432]

Ok so I found a keymap.c for the Cheapino here: https://github.com/JordanNiphan/CheapinoQMK/tree/main/keyboards/slaet and using that was able to get the debug working by adding the code snippet at the bottom to keymap.c (snippet from the QMK debugging FAQ). I also added a define to config.h for it to display the matrix scan frequency (looks like it's usually around 3100 on mine). I get output along these lines for all of the working keys (though the 6 that aren't working don't output anything in the debugger). When I short the 1 and 4 pins, for example, I only get one key press (the "C" key but not the "X" key) - though shorting other pin pairs generally registers two different key presses except the 6 keys that aren't working, which only gives one key press. It makes no sense! I did order a few more of the RP2040-zero since they're so cheap so I'll let you know when they arrive if swapping a new MCU in resolves the issue.

I also realized that I did use a flash "nuke" .uf2 to reset both boards after I initially configured them wrong. I'm wondering if that nuke was intended only for the Pi Pico and did something strange to the RP2040-zero or its second stage bootloader or something. But otherwise I'm completely out of ideas so will stop bothering you here! I can't emphasize enough how much I really appreciate all of your help with troubleshooting, etc. Thanks again!

Keyboard: KL: kc: 0x0014, col:  4, row:  0, pressed: 1, time: 18951, int: 0, count: 0
Keyboard: KL: kc: 0x0014, col:  4, row:  0, pressed: 0, time: 19107, int: 0, count: 0
Keyboard: matrix scan frequency: 3135

FYI - here's the debug code I added to keymap.c to get the above output.

bool process_record_user(uint16_t keycode, keyrecord_t *record) {
  uprintf("KL: kc: 0x%04X, col: %2u, row: %2u, pressed: %u, time: %5u, int: %u, count: %u\n", keycode, record->event.key.col, record->event.key.row, record->event.pressed, record->event.time, record->tap.interrupted, record->tap.count);

  return true;
}

[tompi]

Okay, Im starting to Wonder if this might be caused by gp4(row 3) being shorted to ground.

Could you check if k18 is also defunct? (This is the left/innermost thumb key on the left part)

Please check carefully if gp4 is shorted to ground somewhere, maybe the housing of the rj45 port or at the mcu soldering.

[mkw432]

I think you were exactly right (K18 also wasn't working) but I couldn't locate the short anywhere. There were a few tiny nicks I made in the PCB that could've caused it. The good news is that I used a spare RP-2040 Zero on my last remaining PCB and moved over all the switches and now it's working perfectly! I also added the 3D printed case and plate (only on the left side) and am typing on it right now! Thanks again for all of your help.

[tompi]

Yeah, if the nick tore off a track that might be the cause. Anyway really nice to hear you got it working in the end!!