PCB CH32x-48

[rgoulter]

Copy-pasted the CH552-48 with its TSSOP-20, changed it to use the TSSOP-20 CH32X033F8P6.

Uses https://github.com/rgoulter/smart-keymap for its firmware.

Unfortunately, in rev2025.1, the arrangement of ROWx/COLx conflicted with restrictions the CH32X035 has on which pins can output, & which pins can be pull-down inputs. -- This was fixed by flipping the diodes around.

rev2025.2 fixes this, includes a note about this in the schematic. rev2025.2 also adds a second decoupling capacitor.

rev2025.3 increases the signal trace width to 0.25, and adds a 10k pullup resistor for row6/DIO.

I haven't fab'd/tested rev2025.3.

---

Kibot-generated assets for CH32X-48 rev2025.3:

• Schematic: keyboard-ch32x-48-schematic.pdf
• Gerber-zip: keyboard-ch32x-48-gerber_zip.zip
• PCBA JLCPCB BOMkeyboard-ch32x-48_bom_jlc.csv
• PCBA JLCPCB POS keyboard-ch32x-48_cpl_jlc_bottom_pos.csv

[rgoulter]

Will make a proper release later, if all seems well.

[rgoulter]

And the schematic:

keyboard-ch32x-48-schematic.pdf

[rgoulter]

I'm observing issues where if a SW_2_C is pressed quickly followed by a SW_6_C, then most of the SW_6_C keys are ghosted.

The traces on CH32X-48 are 0.2mm, on CH552-48 they were 0.25.

[rgoulter]

I'm observing issues where if a SW_2_C is pressed quickly followed by a SW_6_C, then most of the SW_6_C keys are ghosted.

I was able to troubleshoot this further.

This comment was inaccurate. It's the other way around:

• if a SW_6_C key was pressed quickly followed by a physically adjacent SW_2_C key, then all SW_6_C keys scanned as pressed.

Some other observations:

• observed no issues pressing a SW_2_C key followed by an adjacent SW_6_C key. (i.e. the order mattered).

• observed no issues pressing a SW_6_C key followed by a different adjacent key.

• observed no issues pressing a SW_6_C key followed by a non-adjacent SW_2_C key.

• Row 2 is PC19, also used for 2-wire SWD CLK. Row 6 is PC18, also used for 2-wire SWD IO.

• The traces of CH32X-48 rev2025.1 are largely the same as CH552-48; except on the CH32X-48, they're 0.2mm instead of 0.25mm.

• The issue could be reproduced even after increasing the delay after "clear column pin" in matrix scan.

• The issue could be reproduced even after increasing the number of scans required in the matrix scan.

• I could no longer reproduce the issue after soldering a 10K resistor pulling Row 6 up to 5V. (I just used a TH resistor on the broken-out SWD pads; reproduced the issue without the resistor, CNR with the resistor).

The datasheet mentions SWD is enabled by default, and can be disabled by the software. I can't see anything in particular about this in the provided EVT's SDK. I would have thought configuring PC18 (DIO) to IPU would be enough. -- But, if it were an issue with SWD as AF, then I'd not expect the reproduction to be as precise as the above.

I'm not really sure I understand what the issue was. It's my understanding that the 10K resistor is has lower resistance than the internal pullup for the CH32X (hence a stronger pullup).

I tried using a 10k pullup to 5V from DIO on the WeAct CH32X core board. I was still able to use the WCH Link, and still able to flash using ISP. So, seems fine to add. (Also seems that external 10K pullup is not unusual for e.g. STM's SWD IO pin).

rev2025.2 (shared in the PR) fixed the diodes for the arrangement of rows/pins. I'll revise again; using thicker traces, and adding a 10k R between row6 and 5V.

[rgoulter]

Kibot-generated assets for CH32X-48 rev2025.3:

• Schematic: keyboard-ch32x-48-schematic.pdf
• Gerber-zip: keyboard-ch32x-48-gerber_zip.zip
• PCBA JLCPCB BOMkeyboard-ch32x-48_bom_jlc.csv
• PCBA JLCPCB POS keyboard-ch32x-48_cpl_jlc_bottom_pos.csv