[request] Troubleshooting Guide

[ssokolow]

I just built what should be a functioning ps2x2pico, but it's not.

1. The pin assignments between it and the level shifter are all as described in the README.
2. It does show up for programming if I BOOTSEL, so the chip isn't dead.
3. The power LED does come on when it's being powered off its PS2 side by a PS2-to-USB adapter (I don't want to risk plugging it into the vintage machine until I trust it)
4. The USB Type-C OTG adapter does allow me to successfully plug the test mouse or test keyboard into a modern PC's USB Type C port and use them.
5. For the surrogate vintage PC, I've tested with both a $3 eBay PS2-to-USB adapter and a $20-30 ioGear adapter from 10+ years ago with the same Chesen chip used by this high-quality StarTech adapter and both work fine with the test keyboard and mouse when talking to them directly.
6. I double and triple checked and couldn't find any solder bridges or places where I should be getting continuity but am not.

...but the test input devices just don't come up when I plug them into it via the USB OTG adapter and then plug it into the modern PC via the PS2-to-USB adapter for the smoke test. (The LED for the optical sensor on the mouse doesn't light, and the keyboard doesn't do anything)

I thought maybe these lines were indicative of Dolphin's file copying interacting badly with the Pi Pico's "reboot when it thinks you're done sending the firmware" behaviour...

[1269453.915631] device offline error, dev sdd, sector 260 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 2
[1269453.915636] Buffer I/O error on dev sdd1, logical block 259, lost async page write
[1269454.128385] FAT-fs (sdd1): unable to read boot sector to mark fs as dirty

...so I tried using cp /home/ssokolow/inc/ps2x2pico.uf2 /media/ssokolow/RPI-RP2/ and cp /home/ssokolow/inc/ps2x2pico_5628f15_200hz.uf2 /media/ssokolow/RPI-RP2/ instead, which did cut it down to this...

[1270597.093027] FAT-fs (sdd1): unable to read boot sector to mark fs as dirty

...but no change in results from either firmware version.

There needs to be some kind of guide to what to do next to diagnose "thing doesn't work but it doesn't appear to be an assembly problem".

(I have no experience with the RP2040. What minimal experience with microcontroller programming I do have is all Arduino Uno plus Arduino IDE and STM32 Blue Pill + STM32duino + cheap Chinese ST-Link clone... dammit, Jim, I'm a PC and web developer not a microelectronics guy! With things as they are, I'm basically just stuck tossing what should be a couple of pieces of electrical tape, a squirt of hot glue, and a few screws away from being a fully assembled and cased ps2x2pico into the closet and putting up with reaching for the rear of my two keyboards when I want to practice programming for Windows 98 SE.)

[No0ne]

Hi! Can you hook up to serial port on GPIO0 with settings 115200n8, there should be debug output on boot and on usb events.

[ssokolow]

Sure. Give me a sec to dig up a 3.3V-compatible USB-TTL Serial adapter and see if I can find my ready-made test-clip leads for it. (I'm way overdue for re-organizing my electronics things based on what actually gets used together.)

[ssokolow]

I just get <newline>ps2x2pico-1.0<newline> and that's it.

(Well, assuming there aren't any unprintables. I'm just using screen /dev/ttyUSB0 115200 8N1.)

EDIT: Added the initial newline which I'd missed because I was distracted by some line noise from a previous attempt where the test clip had slipped off without me noticing.

[No0ne]

Mhm there seems something wrong on the USB side. Is 5V present? Try without a hub.

[ssokolow]

That was with it powered from the PS/2 side via a USB-PS2 adapter and an un-hubbed mouse hanging off the USB side. However disconnecting everything except the GPIO0 test clip and then powering it off a USB C cable on the USB side doesn't appear to change anything.

[No0ne]

Can you test with another USB device? Check if it is really powered.

Upload a photo if you want.

[ssokolow]

Define "with another USB" device. Am I supposed to be replacing the ps2x2pico with something else to test that the port is good, or am I supposed to be replacing the mouse to test that side of the equation?

...because I've already tried plugging the ps2x2pico into another port via a USB A-to-C cable so I could use my Charger Doctor to verify correct voltage and measure amperage. It wavers between 5.01V and 5.00V whether it's on one of my case's front-panel USB 3 ports or one of the USB 2 ports I exposed via a 3.5" bay, same as what the Charger Doctor reads when it's powering a USB-PS2 adapter to test powering it from the PS/2 side without putting any vintage tech at risk.

[No0ne]

I meant a different usb mouse or a usb keyboard. There should be a message on the serial output when a USB device is detected.

[ssokolow]

I just tried plugging a second Charger Doctor in between the mouse and the ps2x2pico. While the ps2x2pico's power light is on, the Charger Doctor on the USB side either isn't getting any power or isn't getting enough power to turn on when powered from the PS/2 side.

[ssokolow]

Give me a sec. I recently bought a cable to break out the power lines from a USB Type A into alligator clips. I'll grab my multimeter and see if it's getting voltage but not enough.

[ssokolow]

Yep. Multimeter says there's 5.02V on the PC's USB Type A port, but only about 0.1V on the ps2x2pico's USB Type C port when powered from a PS2-to-USB adapter via VBUS. (It seems to be some kind of unregulated trace value because I've seen it crawl down from 0.17V and up from 0.08V.

[No0ne]

mhm thats what I suspected. VBUS also feeds the USB micro port and VSYS only provides power for the pico itself.

[ssokolow]

So you're saying the silkscreen on this board and the documentation I read have different opinions about whether VBUS or VSYS should be labelled as Vin?

[No0ne]

Which RP2040 board do you have?

[ssokolow]

A Chinese clone, because shipping on the name-brand ones was prohibitive for single-unit orders.

[No0ne]

Then maybe this has a diode between Vin and the USB port and can't send power out the USB port.

[ssokolow]

If getting VBUS and VSYS mixed up won't cause any permanent damage, I'd be willing to pull the soldering iron back out and try plugging the power into "Vout" to see if they labelled them backwards from the guides I read.

[No0ne]

Ok! Seems to be related to this: https://github.com/No0ne/ps2x2pico/issues/22

[ssokolow]

As for the diode hypothesis, give me a sec to play around with the USB-Alligator lead and my multimeter.

[No0ne]

Based on the photos in #22 Vout seems to be VBUS and Vin is VSYS so Vout should be right.

[ssokolow]

I'll try swapping the wire anyway, just in case, but I think there's also a diode. I'm getting an open circuit from the USB 5V line to Vout OR Vin in one direction but not the other.

EDIT: At least, assuming I'm remembering how my multimeter behaves in this context. I did say I was a novice.

[ssokolow]

Hah! I just noticed that the duplicate silkscreens on the bottom include parenthesized (VBUS) and (VSYS) and Vout is VBUS. Give me a sec and I'll PR a fix for that change to the README.

[No0ne]

I look at the PDF from #22: https://github.com/initdc/YD-RP2040/blob/master/YD-2040-2022-V1.1-SCH.pdf Indeed Vout is also connected after the diode BAT54C. So there seems no way to output 5V by connecting to VBUS on this board.

Does it work on your board now?

[ssokolow]

I was already out in the garage. It is a YD-RP2040 (says so on the underside silkscreen) and, as you might expect, it still doesn't work.

Well, that's 4.60 CAD down the drain. If I wanted to spend five bucks on a board I can't use for this application, I'd have bought another ESP32.

Now that the nature of the problem has been confirmed, maybe it's time to add a compatibility list to the README in addition to an easy-to-find guide to things like the bit about getting debug output from GPIO0 and how, if you have these symptoms and your board isn't explicitly listed as compatible, check if the USB port is getting any power when powered from the PS/2 side.

[No0ne]

The easiest fix would be just to bridge and/or remove the diode.

[No0ne]

Or connect the PS/2 5V directly on the diodes VBUS leg.

[ssokolow]

In both cases, I have two things to say:

1. Would that engender any risk to the devices it's plugged into? I'm kind of paranoid about that.
2. I'm gonna need a better magnifying glass

(Seriously. This looks like it'll be a $4.60 opportunity to practice interacting with surface-mount components so small I can barely see that they exist... I'm glad my brother threw in a more SMD-sized tip when he bought me my Hakko as a Christmas gift.)

...well, I suppose the latter option isn't so bad, size-wise... though the solid wire I tend to use for jumpers is still possibly bigger than that pad.

[No0ne]

The only risk I can think of is if you have plugged in PS/2 and USB to another computer for firmware upload. This would short both 5V rails or worse if the PS/2 computer is powered of backpower that 5V via the pico, which is probably not good.

But if you always disconnect both PS/2 connections while firmware updating there sould be no problem.

[ssokolow]

So basically the same caution as with the STM32 Blue Pill or Black Pill boards. (No protection between the USB connector and the power supply pin on the programming header you plug your cheap Chinese clone ST-Link into.)

Judging by the schematic, the least fiddly way to do this is to scrape away the solder mask between those two input legs on BAT54C, add some solder to bridge them together, and then move the wire back to Vin.

(The centre-ward leg is connected to the USB C and the edge-ward leg is connected to the Vin pin... on the opposite side of the board. It appears to do so by ducking in between the mechanical supports for the USB C port and passing under its body.)

EDIT: *facepalm So Vin is* technically VBUS and the underside silkscreen is wrong... it's just that, in the YD-RP2040, that two-legged Schottky makes it a mostly irrelevant distinction since they're both on the input side of the voltage regulator anyway.

[ssokolow]

Nope. Looks like I just made it harder on myself. The now-exposed copper between them is ground plane.

Hmm. Maybe if I bridge between the two traces further away with a bit of resistor lead and then put some clear nail polish on the exposed ground plane to seal it back up so there's no risk of shorting.

In hindsight, I should have just left the solder mask on and tacked a bit of resistor lead between the two legs of the Schottky. Oh well, live and learn.

EDIT: Probably also too fiddly. I'll just have to lift the Schottky and then wing it about getting some resistor lead into a Y pattern without bridging onto that exposed ground plane.

EDIT: I suppose a $4.60 device I have no use for otherwise is as good a time as any to experiment with using the heat gun I bought for shrinking heat shrink to do the most basic hot air rework job in existence.

[ssokolow]

It took several false starts, including grinding the top of the Schottky off with my Dremel because it wouldn't lift, so I could use it as more not-overlapping-with-the-exposed-ground-plane pad to solder to, only for it to then lift because of the greater surface to receive heat, but I present my submission for the "Ugliest functioning ps2x2pico" contest.

(It still needs some IPA and a toothbrush to get rid of the excess flux, electrical tape around those wire joints because I forgot to slip heat shrink on first, some clear nail polish over the concerningly-close-to-VCC patch of exposed ground plane, and the case I prepared for it, but it does work and, aside from having tested it with the USB-to-PS2 adapter instead of the repurposed HP t5530 thin client, it works in exactly the configuration I want to use it in.)

EDIT: Oh, and as befits a cheap Chinese clone board, it also needs some hot snot for strain relief.

NOTE TO ANYONE CONSIDERING DOING THIS: This approach is a hack to work around a previous attempt that only turned out to be a bad idea after I'd scraped solder mask off some ground plane. Instead of removing the barrier diode entirely, I'd suggest just tacking a piece of resistor leg between the two legs of BAT54C that face the USB C connector. That's much less fiddly and allows current to flow from Vin to the USB port without losing diode protection on the rest of the board.

[No0ne]

Thanks, I updated the Readme.md