PS4 Forced Mode using HOTKEYS causing unexpected behavior for D-PAD inputs. Using WEBMODE to set PS4 mode, D-PAD Operates as expected

[JasensCustoms]

Expected Behavior

Pressing PUNCH 2 on plugin places Pico Fighting Board into PS4 mode. Directional inputs in Windows JOY.CPL work properly.

Current Behavior

Pressing "PUNCH 2" to force the Pico Fighting Board into PS4 mode, D-PAD directions do not operate properly. Using Windows JOY.CPL shows that UP+LEFT is pressed. Pressing any other directional inputs causes the indicated direction to change, but not correctly. All other buttons work correctly.

When forcing the Pico Fighting Board into PS4 mode via web config, D-PAD directions work as expected in Windows JOY.CPL.

Pressing "KICK 2" to force the Pico Fighting Board into XBOX (XINPUT) mode, D-PAD directions work properly. When using Windows JOY.CPL all directions work properly. All other forced modes for the PICO FIGHTING BOARD works correctly.

Context

• Firmware version: Fresh download of the Pico Fighting Board V0.7.10
• Hardware: Integrated Pico Fighting Board (All Versions)
• Purchased From: http://www.jasenscustoms.com
• Windows 11
• Chrome

Steps to Reproduce

Using button HOTKEY method to FORCE MODES

1. Plug the Fighting Board in while holding P2
2. Observe Fighting Board enumerates in JOY.CPL
3. Click the Properties button, observe the input lights on JOY.CPL and current status without anything pressed
4. Press buttons and verify button inputs work

When using WEBCONFIG to place board in PS4 Mode.

1. Plug the Fighting Board in while holding START
2. Navigate to Web Config
3. Set Joystick to PS4 mode.
4. Click Save.
5. Reboot to Controller Mode.
6. Observe the fighting board enumerates in JOY.CPL
7. Click the Properties button, observe the input lights on JOY.CPL and current status without anything pressed
8. Press buttons and verify button inputs work (they do).

Using WEBCONFIG MODE, NO BUTTONS PRESSED:

Using FORCED MODE, NO BUTTONS PRESSED:

[TheTrainGoes]

Several of us tested this and were not able to replicate given the information above.

It is not clear if you used our GP2040-CE_0.7.10_PicoFightingBoard.uf2 firmware to test this or your own.

Were any additional changes made to the settings or are you using the defaults of the PicoFightingBoard?

My test:

• Fresh Pico
• Nuke
• Fresh download of PicoFightingBoard put on
• Unplug
• Replug with P2 held down

I also tested setting as the various modes of PS4/5 and could also not replicate.

Possible issue with the Integrated Pico Fighting Board or custom firmware (if being used).

[JasensCustoms]

1. This is a fresh, new PCB.
2. There is no custom or modified firmware for the IPFB, it uses stock GP2040-CE firmware downloaded from the GitHub. Specifically, the PicoFightingBoard V0.7.10 UF2 as stated above. To ensure there were no conflicts, no changes were made in webconfig after the flash except when swapping modes to replicate behavior.
3. The same steps above were followed and the issue persisted.
4. This only occurs in the PS4 Forced Mode using P2 being held down; all other forced modes operate correctly.
5. The IPFB follows the RP2040 design guide exactly as written by the Pi Foundation and operates as intended in all other forced modes or when pushed to PS4 using the webconfig.

[TheTrainGoes]

I have tested this on the following devices with the following firmwares and have not been able to replicate:

1 - Haute42|COSMOX S16 -> GP2040-CE_0.7.10_Haute42COSMOX.uf2
2 - RP2040 Advanced Breakout Board v5.6 (Version 2) -> GP2040-CE_0.7.10_RP2040AdvancedBreakoutBoardUSBPassthrough.uf2
3 - Raspberry Pi Pico -> GP2040-CE_0.7.10_Pico.uf2
4 - Raspberry Pi Pico -> GP2040-CE_0.7.10_PicoFightingBoard.uf2

I also loaded GP2040-CE_0.7.10_PicoFightingBoard.uf2 onto the IPFB 'November 2022' board I have and was not able to replicate.

Of note here is that when I attempted to put GP2040-CE_0.7.10_IntegratedPicoFightingBoard.uf2 from https://github.com/JasensCustoms/GP2040-IPFB/releases/tag/v0.7.10 onto the IPFB 'November 2022' or a stand alone Raspberry Pi Pico it caused the unit to lock up and would not show up in either Windows JOY.CPL or the online hardware tester (https://hardwaretester.com/gamepad).

---

Re: 2 - It is my understanding that the IPFB runs on a custom configuration of GP2040-CE as available from https://github.com/JasensCustoms/GP2040-IPFB/releases/tag/v0.7.10 under the name GP2040-CE_0.7.10_IntegratedPicoFightingBoard.uf2. Outside of this I was able to load our hosted GP2040-CE_0.7.10_PicoFightingBoard.uf2 onto the device and could not replicate the issue.

Re: 5 - The IPFB is a closed source device and not supported by the project.

---

If you are able to replicate this on a device that we support like the Raspberry Pi Pico running our hosted GP2040-CE_0.7.10_Pico.uf2 please let us know and we will investigate further.

[TheTrainGoes]

Shortly after my last comment I can see that the IPFB was open sourced via https://github.com/JasensCustoms/Integrated-Pico-Fighting-Board?tab=readme-ov-file.

I was able to download both the board file and the schematics to EasyEDA and take a look.

The converted import into EasyEDA produced a number of DRC errors but this is common so they were omitted during my look.

There only thing that stood out to me on first pass was the crystal oscillator (C409301).

The provided schematics (https://github.com/JasensCustoms/Integrated-Pico-Fighting-Board/blob/main/eagle-cad-files/integrated-pico-fighting-board-gp2040-layout-Version3.0.sch) Only reference XIN being connected for the oscillator where the RP2040 Hardware Design document (https://datasheets.raspberrypi.com/rp2040/hardware-design-with-rp2040.pdf) shows XIN and XOUT connected to the crystal oscillator.

I am not familiar with the crystal oscillator used in this design (C409301), only C9002 which I use on my own designs.

There was a period of time a few years ago where some crystal oscillator related issues were observed at startup which could causing unexpected behaviour. We addressed this by adding a small delay on startup. I am unsure if this specific crystal oscillator may also be causing issues.

---

Outside of this it would be important to know if this can be replicated on any boards other than the IPFB.

[JasensCustoms]

This design uses a CMOS oscillator, not a crystal. The use case was validated by the Director of Engineering at Abracon who provides the actual CMOS oscillator used in my builds (the LCSC part was the closest available for the BOM to ensure there was no questions about the design, but it also works the same way). This was a change based on the slow startup of some crystal oscillators you noted causing issues. I consulted them to ensure I used their device properly since it was a significant change. As such CMOS oscillators do not require a connection to to the XOUT as they do not have an OUT pin.

From the design doc:

"Providing an external frequency source can be done in one of two ways: either by providing a clock source with a CMOS
output (square wave of IOVDD voltage) into the XIN pin, or by using a 12MHz crystal connected between XIN and XOUT.
Using a crystal is the preferred option here, as they are both relatively cheap and very accurate."

I don't use other boards using the GP2040-CE firmware, so I can't comment if this can or can't be replicated.

[TheTrainGoes]

Does this happen consistently on the IPFB or sporadically?

If consistently can you please do a UF2 flash dump of your IPFB that exhibits the issue and I can test on other RP2040 based devices.

Are there any other factors which may be affecting the operation of the IPFB such as connected accessories / add-ons / etc (dongles, screens, LEDs, etc) or are you able to replicate this issue with an IPFB connected on its own to the computer?