SCH error - Cirque Overvoltage from J2/J3

[TheWerle]

Digging through the Build Log and I think I know why you can't get the Cirque to work. Sadly its because I suspect you've blown it up.

Cirque input voltage is 3.6V max tolerance per datasheet, nominally 3.3V or 1.8V to match the I/O logic levels of whatever device controls it. Your J2/J3 headers are attached to VCC, and as I detailed in VCC will be in the 4.5-5.0V range for all your operating conditions.

J2/J3 power connections need to be reassigned to 3V3.

[JellyTitan]

You might be right!
I went with the BeeKeeb breakout board with the adaptation for I2C Sofle V2 - so it should be 5v tolerant?
https://shop.beekeeb.com/product/23mm-cirque-glidepoint-circle-trackpad-module/
https://beekeeb.com/cirque-trackpad-i2c-on-corne-keyboard/
I suspect the problem is with how I configured QMK, or a conflict with a default I2C address.
I did add a cutout for that jack to all the cases though, so there may be some hope yet.

[TheWerle]

Ok, yeah based on the guide its still unclear. I2C/SPI is set by the R1 resistor, if your circque board still has R7/R8 installed you cooked it, the guide is unclear on the state of the board as delivered.

https://www.mouser.com/ProductDetail/Cirque/TM023023-2024-002?qs=wd5RIQLrsJhgKZTW4CXgsA%3D%3D
if you need a new one the pad alone is far cheaper.

I'd make a ticket to swap the headers to 3.3V in the future. The trackpad controller datasheet is here, based on the pics R7/R8 are the internal regulator connection resistors. If you keep them installed and power it off 3.3v it should work no matter what.
https://www.cirque.com/gen2gen3-asic-details

Update: found ribbon pinouts and a larger board image where I can make out traces. I think it sufficiently verifies that R7/R8 are equivalents for the power jumpers in that SCH snippet, and if installed you overvolted the module.
R7 = R5 DVDD 22 ohm series resistor
R8 = "R4" AVDD 0 ohm jumper resistor

[TheWerle]

Found a "close enough" schematic that broadly matches the displays, FWIW.
https://files.seeedstudio.com/products/104020249/Grove-OLED-Yellow&Blue-Display-0.96-(SSD1315)_V1.0-SCH.pdf

Looking into I2C with my logic analyzer to see the signal integrity for drive-strength and waveform quality. The lack of external pull-ups on the I2C just weirds me, I'm trying to find the way QMK pulls the bus in their HAL.

There's definitely some potential for problems here adding more bus devices, on short period SDA bursts the waveform only jumps to ~1.8V, and on sustained pulses SDA droops between clock cycles. This is likely a side-effect of weak bus drive strength from just using internal pull-ups on SDA/SCL, along with natural capacitance on the data lines or pulls on the peripherals.

I added a pair of 4.7k pull-ups from the spare headers to 3.3V, and the short pulses jump from ~1.8V to ~2.5V in the same spots. The clock waveform is also significantly less sloped, inherent to the increased drive-strength on the line. Adding an optional pair of TH/SMT combo pull-up pads to a future board rev would probably be prudent, or drafting some instructions for optimal locations to add thru-hole resistors into the unused poka-yoke header pads.

EDIT: Talked to QMK discord gurus, part of the problem is potentially my swapping to stable 3V3 rather than VSYS on I2C header power. The 4.7k pull-ups preinstalled on the OLEDs are definitely too large a value, and there was a known ChibiOS bug (recently fixed) in the RP2040 clock PLL for I2c data rate, but I don't know if that's rolled into the existing Sofle-Pico Builds.

ChibiOS/ChibiOS-Contrib#382

By adding ~2.2kohm pull-ups in parallel to the OLED between the header pins I get a measured 1.8kOhm pull resistance to 3V3 and consistent logic > 3.0V, which should be good.

RP2040 Input HIGH logic is 0.6*VDDIO ≈ 2.0V at 3.3V, if SDA doesn't exceed that it could definitely impact data-reads from a trackpad/trackball/etc. For any Sofle-Picobuilds with read/write I2C devices I'd recommend adding parallel 2.2 pull-ups to guarantee a solid waveform logic level.

EDIT: 3/28/2024 retest of Sofle-Pico 3.5.4 MX switch boards @JellyTitan sent me

Default I2C exhibits similar issues of "too-low for trackpad" I2C logic levels, only reach ~1.65V on single-clock cycle data bits. 3.3V or ~4.8V values for "VCC" don't matter because the OLEDs have an onboard regulator for 5V->3.3V conversion that pulls I2C to the same potential, so the droop is roughly equivalent regardless of the primary input voltage.

2.2K pullups to 3V3 from Pin36 to nearby J3 SDA/SCL pins. It would probably be cleaner to route them across the Pico from Pin 36 to pins 9 and 10, but I wanted to keep them short.

[TheWerle]

https://github.com/pfn/qmk-firmware-charybdis

This reddit user has a Charybdis he's modified with a highly functional QMK cirque setup. I am trying to figure out how to integrate some of that but thus-far utterly lost because I have the coding skills of a board designer (aka little/no skills.).

UPDATE: after more research / browsing i think a better port-able building block to reference is the OG bastardkbs "dilemma" code. Its more in-line with the "add stuff at the user level configs setup that we should be baselining from.
https://github.com/Bastardkb/Dilemma

[JellyTitan]

I'd recommend adding parallel 2.2-4.7k pull-ups to guarantee a solid waveform logic level.

I'm out of my element on this. Did you happen to add that to the Sofle Chico?

[TheWerle]

I'd recommend adding parallel 2.2-4.7k pull-ups to guarantee a solid waveform logic level.

I'm out of my element on this. Did you happen to add that to the Sofle Chico?

Not in a formal sense of "I added specific pads for that purpose", but I personally soldered 2.2k 0603 resistors between VCC and SDA/SCL pins on the J3 OLED headers. 0805 or 1206 parts would fit better, but I used whatever I had lying around.

There's plenty of redundant I2C header pins to go around for adding pull-ups as needed, SMT or TH. The bigger question is whether to change the header power pins to 3V3 or keep them as VSYS in the baseline design. If we made that change we might as well throw in some SMD pads while we're at it.

[TheWerle]

OH HELL YEAH I've got the trackpad working! Just touch, no buttons yet, but I figured out the missing "config.h" settings and now the mouse moves and scrolls.

I had to add the following to rules.mk

POINTING_DEVICE_DRIVER = cirque_pinnacle_i2c
POINTING_DEVICE_ENABLE = yes

Added these to my userspace config.h

#define MASTER_RIGHT
#define CIRQUE_PINNACLE_DIAMETER_MM 40
#define POINTING_DEVICE_GESTURES_SCROLL_ENABLE // Circular scroll.
#define CIRQUE_PINNACLE_TAP_ENABLE

I also commented out the 90deg rotation #define from the sofle-pico "config.h". That should probably get removed in favor of a per-user rotation unless/until there's a Sofle-Pico specific case component specifically aligned with it. I designed my OLED+trackpad part as 0° oriented and the project default conflicted with my userspace value.

[JellyTitan]

Congrats! That's really exciting! I'm looking forward to trying it out.

Which vendor would you recommend for the cirque?

On the QMK side, I'm getting a little beat up with the PR. (Which is actually kinda good - someones taking the time to tear it apart immediately)

They are now asking that all default keyboard layouts be stripped down to bare minimum, so that the user can use them as a starting point for customizing stuff themselves.

I'm not sure what the new method is for sharing the more fancy features. . .

[TheWerle]

I bought my trackpads direct from mouser with no "kit" for the flex because I knew I wanted to iterate my own OLED+mount design, so my wiring is a total hack atm.

If you choose to make support standard I'd either point people to the 4pin you got from beekeeb, as the kit or open source adapter link, or just suggest direct test pad to wire soldering on the bottom of the pad with strain relief epoxy or something.

[TheWerle]

Wired the trackpad into the "Pomoroni" header with the unused pin wired to 3V3 and verified trackpad functions on the MX 3.5.4 board with my pre-"fancy" config. I'm going to try to initially maintain the MX boards as a "control" where I don't work too far ahead of the main repo so I can independently verify the commits as you go thru the PR process, but still happy to have things working easily on both sets of boards.

[JellyTitan]

I'll defer to your judgment on the best approach for all things electrical. I'm starting to feel like the patch bay should be dumped to free up room for new and exciting features.
With the new QMK approach to only allowing MVP keymaps - there is pointing device config allowed - not even key based mouse control. As long as the basic key matrix, encoder pins, and communication pins don't change, there shouldn't be anything blocking a pimoroni/trackpad rewire.
I can take down the supporting pimoroni docs during the rewire/testing phase if need be.
Keep up the great work!

[TheWerle]

I wouldn't outright get rid of the patch bay, its conveniently located as-is, brings out the bulk of the remaining available pins, and in the right general area for folks to bolt on something new or fork their personal board/case design to to fit in trackball housing or whatever. Once you've built up the case its pretty harmless. Dropping overt support for add-on stuff that is QMK baseline makes sense too, lower your configuration management overhead and keep it on the end-user to improve functionality. If folks want polish they can pay for it it somewhere else, we're offering a base-platform.

From what I've seen if we provide any sort of functional mechanicanal option for touch device integration at launch it would position the Pico very appealingly in the DIY/beginner space. It was a significant part of what lured me in. I'm trying to learn more "proper" methodology in Fusion for my current tray design to make it both angled, rotatable, and dynamically scaleable so I can knock out 40/35/23mm versions that will fit with either switch variant and the existing OLED plates, but even then I don't know if its worth including in the base design.

[JellyTitan]

That adjustable mounts looking great!

I don't know if you've started using variables in Fusion 360 yet, but they are super helpful. (i think they really should appear pinned in the default toolbar 🤷 )
It's tough integrating with FDM and parametrized designs though - FDM layer orientation & overhangs drastically impact the design. (Since the advent of organic supports - i don't worry about overhangs too much - but I'm still painfully aware of the surface finishes).
I really got a ton out of this course. I took it about 5 years after I had started messing with 3d printing and CAD, and i still found a bunch of 'unknown unknowns'.

I wouldn't worry too much about working within the confines of the existing OLED plates - it's about $1 plus shipping for cut acrylic at that size, so making a few OLED plate variants available is reasonable. (As long as the PCB holes and the key/back plate holes remain the same.)