-
Notifications
You must be signed in to change notification settings - Fork 12
Dev Notes
This page is meant to keep track of design considerations made and some other software development notes. This page is mostly meant for developers.
I selected VSYS instead of VBUS since this takes the +5V rail after the diode on the pico. This provides some protection against sending voltage spikes to the USB port, but it does cause a bit of voltage drop. The voltage drop across the diode is about 0.2V. I tested how low the input voltage can be with a standard DC controller with a VMU and PERFORMANCE jump pack. It seemed to tolerate input voltages from the USB port down to 4.5V. The VMU screen started to look washed out and VMU data access was problematic with an input voltage lower than this. USB ports should output at least 4.75V if it's adhering to the USB spec.
I have noticed more issues with the cheap NAKI jump packs I have. They work better when the controller is getting its 5V directly from VBUS.
In my own tests, I have measured max of 570 mA current draw with 4 fully-loaded controllers attached while all jump packs are activated at full power using a 4-player version of this device (see stress test on settings page). The original Dreamcast controller port came with a 800 mA fuse, and USB 3.0 ports should be spec'd to supply at least 900 mA. The supplied power is shared across all devices on the bus though, so an externally-powered USB hub may be needed in some circumstances.
I think if having a jump pack activate makes this device malfunction, that means the jump pack is drawing more current/power than the connected USB port can handle. This is exactly what I noticed when I current-limited the 5 V supply. It wasn't enough to cause the USB device to reset, but it was enough to start causing the controller and peripherals to malfunction.
I wanted to at least provide a bit of fault protection on these data lines since the GPIO on RP2030 are a bit fragile. These resistors also block some voltage reflections, but I didn't notice any communication issues without these resistors in place. Any resistor value over 80-ohms started to affect communication for some controllers (mainly the arcade stick). This is why I settled on 50-ohms.
I wanted to select a minimum value resistor such that if all 8 data lines experienced a fault, the total current draw would be below 50 mA that the GPIO can handle. 3.3 V / 560 ohm * 8 = 47 mA. It seemed like communication was still processed with 1k-ohm resistors used, so I don't feel like this value of 560-ohm reaches any sort of communication integrity limit.
The outputs of 74LVC2T45DC chips are limited to 50 mA. Therefore, I chose a slightly higher resistance here than the safe configuration in order to be below 50 mA during a fault at 3.3 V. A fault where the 5 V is shorted to a data line will technically go over the chip's rating, but the bus is normally high (at 3.3 V) through a pull-up resistor and only transitions to output low for a tiny fraction of time while it's testing for the presence of a peripheral. I've tested for this type of fault and noticed no damage. Damage could occur in a double-fault scenario where the 5 V supply line is shorted to a data line and there is a fault in the firmware (like incorrect firmware loaded).
To attach a USB device such as the debugprobe, first execute the following in WSL.
sudo modprobe vhci-hcd
Then open a Powershell with admin privileges and execute the following.
usbipd list
usbipd bind --busid <bus_id_in_list>
usbipd wsl attach --busid <bus_id_in_list>
The launch.json configuration named "Pico Debug (Cortex-Debug)" is setup to load and attach to the running firmware.
If WSL is being used, the following needs to be setup in the WSL instance.
- Enable systemd and start udev by editing
/etc/wsl.conf:
[boot]
systemd=true
command="service udev restart && udevadm control --reload-rules && udevadm trigger"
- Add udev rule
/etc/udev/rules.d/99-picoprobe.rules
SUBSYSTEM=="usb", ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="000c", MODE="0666", TAG+="uaccess"
- Restart WSL if either of the above 2 files were written
- Ensure the debugprobe is attached in WSL, see Dev-Notes#debugging-usb-hardware-in-wsl
The following prerequisites are needed to run this in vscode
- Cortex-Debug extension
- gdb-multiarch:
sudo apt install gdb-multiarch - raspberrypi version of openocd: https://github.com/raspberrypi/openocd