PS1 5501 PU-18 rev. 1-644-537-52 random button inputs

[darthcloud]

PS1 5501 PU-18 rev. 1-644-537-52 random button inputs

[williamgentry12]

Hey guys, Just made an account on here to keep track of things and to comment when i find out stuffs :)

[darthcloud]

@ramapcsx2 I'm not using idf drivers in general, too slow and bloated. I'm deeper than the spi_ll API, I'm configuring the peripheral directly myself. Which is base on a snapshot of what the idf driver did once and various experimentation I made.

I tried every single combination of ctrl2 reg config:
https://github.com/espressif/esp-idf/blob/2f9d47c708f39772b0e8f92d147b9e85aa3a0b19/components/soc/esp32/include/soc/spi_struct.h#L84-L98

This include combination not existing in the spi_ll.h or the esp32 technical reference manual

The one I currently got are the best IMHO:

BlueRetro/main/wired/ps_spi.c

Lines 773 to 779 in 03b2979

	/* Set Mode 3 as per ESP32 TRM, except ck_i_edge that need to be 1 for original PSX! */
	spi_hw->pin.ck_idle_edge = 0;
	spi_hw->user.ck_i_edge = 1;
	spi_hw->ctrl2.miso_delay_mode = 1;
	spi_hw->ctrl2.miso_delay_num = 0;
	spi_hw->ctrl2.mosi_delay_mode = 0;
	spi_hw->ctrl2.mosi_delay_num = 0;

[dryja123]

Hey, forgot to mention that the PS1 was sent out to citrus3000psi yesterday. He should have it tomorrow. PixelFX has a N64D launch coming up so it might be a little time until he gets around to looking at it. I told him to take his time.

[dryja123]

Awesome, he said he was sending one out for you. Just wanted to open a ticket so it will be searchable for others, if they have an issue.

[dryja123]

@darthcloud my PS1 is modded with the PS1 Digital and xStation. I’ve tested with and without the memcard pro installed. My first thought was the memcard interfering with the device.

[TerminatorSVT]

I've got 2x PU18 1-664-537-62 with identical mods Xstation and PS1 Digital. Only one has the problem.

The other one generally works but has random issues like SF2 randomly pausing but might just be analog/DS mode I enabled or something, haven't investigated as its fine most everywhere else.

Tested the faulting one by removing the Ps1digital controller flex to no avail. Just saw the 1.2.1 data line voltage update just now and subsequently this thread. No change with 1.2.1.

They might have two diff CPUs. Problem one is a CXD8606Q and cooperative one is a CXD8606AQ.

Since I have two with identical pre-installed mods I could send this one complete to examine if you need it.

[TerminatorSVT]

I just noticed the one you couldn't reproduce the problem on is a AQ under the peeled back shield.

[TerminatorSVT]

Fix: power direct from PS1 3.3v instead of 7v + regulator.

[dryja123]

Fix: power direct from PS1 3.3v instead of 7v + regulator.

Thanks for this, but could you clarify a little more on what you did? Is it just remove the third pin from the right, put it in the middle (just to be off the pad I'm assuming?) and wire it to the regulator?

Just wanted to clarify as I'm decent at soldering but the technical stuff escapes me somewhat lol.

Reach out to Will’s Console Mods. He said he’s going to issue replacements to those who are having this issue.

[TerminatorSVT]

PS has 2x +V pins on the controller port. +3.3v to power controller logic and +7v to power rumble motors.

The old pin location feeds 7v from the rumble and steps it down to 3.3v via the regulator.

For some reason I haven't dug into this is unreliable. There is prob some offset or 3.3 to 7v rail shorting or something wierd going on.

The tab on the SMD regulator is on the 3.3v output side (note this is different from a typical TO-220 style regulator where the tab is GND).

All this does is relocate the pin to the native PS1 3.3v supply and bypassing direct to the 3.3v regulator output side (regulator is thus unpowered). All the tape is just to make sure the pin doesn't touch anything as its floating only by friction with the new shell hole as there is no solder pad to secure it to.

[dryja123]

I ordered up some 220ohm resistors, they’ll be here tomorrow. I can give it a test.

[dryja123]

Yeah, Will and I had a chat about it. The resistors are cheap and we can have a quick definitive answer.

[dryja123]

Awesome, I’ll play around with it this weekend. I also misplaced my breadboard so I ordered one up with a bunch of passives. I can play with the resistor values a bit too.

[darthcloud]

I made some experiment this weekend. In this post I'm looking mainly at the 8V supply. I think it's the proper way forward as it allow the ESP32 to use it's own 3V3 regulator and it's fused to a minimum of 0.8A (1A in practice) vs the 3V5 which is a bit higher than 3V3 and fused to 0.6A.

I think the issue might be related to the ripple on the 8V line which I measured to be around ~700mV. The 3V5 got ripple too but it's much lower which is why I think we had some success with some system "fixing" the issue by switching supply source.

The ripple propagate through the LDO into the ESP 3V3 supply:

Looking at the X-Station ESP32 LDO, I see the supply 8V input is much cleaner:

Which in turn make the 3V3 clean too:

Looking at the PS schematic we can see the 8V supply follow 2 different path. The controller one which is EXT_+8V and the CTRL port use the common DIG_GND. I think the X-Station use the MOT_+8V and MOT_GND. That one goes though an extra LC filter (1uH + 47uF) (Resonant freq circuit?) and one final 4.7uF cap. The GND is (base on schematic) connected to a single point with digital GND.

So i've built the same circuit and added it to the UnoRetro by lifting the LDO input off the pad. The resulting ripple in the 8V supply is much lower but I didn't much improvement in the LDO 3V3 output. We are far away from what the x-station supply look like.

Finaly holding unoretro reset make 8V ripple kind of go away:

But using a low power BT FW or even using the BT off FW have no effect on the ripple.

So no conclusion, maybe you might want to try to had the 1uH inductor and the 47uF and 4.7uF cap before the LDO input on the original 8V unoretro.

I think I'll try next weekend to use a capacitance multiplier:
https://electrical.codidact.com/posts/279580

[dryja123]

@williamgentry12 is sending me a few adapters for testing. If those adapters do not work I would be willing to send my console to @darthcloud for review.

[dryja123]

I received 3 beta adapters from Will, and none of them resolved the issue. I’ve been in direct contact with Darth Cloud and I’m mailing my PS1 out to him tomorrow.

[darthcloud]

Quick update

I've been going through everything single spi timing combination the ESP offer and the current settings look to be the best. Did same with the inline resistor and still get bad reading.

On the scope the data coming from PS look good, data get set sharp on falling edge of clock and so data is good on the rising edge. I don't understand why the ESP read junk.

ESP32 do send junk when it read bad data from PS, this shouldn't happen, I'll try figure why this happen, that wouldn't fix the root cause but at least it wouldn't make random press.

I'll continue this weekend.

[ramapcsx2]

I'm also interested in learning about this problem.
I only have a self made ESP32 DevkitC on a short dongle to test, and so far haven't seen any phantom inputs.

I was initially suspecting the BT radio and all the other stuff would cause the power supply to ripple too much, but this seems to have been ruled out. (Still, that 700mV/10% ripple has to be addressed :p Do at least 100uF and consider a small inductance.)

@darthcloud : You say you tried every SPI delay option on offer? The IDF drivers don't expose every option, and the ESP32 SPI hardware has a lot of bugs and workarounds.
The full option set is in the IDF itself, if you haven't been there yet. Here, for example:
https://github.com/espressif/esp-idf/blob/2f9d47c708f39772b0e8f92d147b9e85aa3a0b19/components/hal/esp32/include/hal/spi_ll.h#L360

Hope this helps? :)

[ramapcsx2]

Haha, check my edit :p
Edith: Yes, certainly possible that the entire upper IO have extra circuitry that skews something. It'd be worth trying to swap, but the big problem is that we need an affected test console.

[williamgentry12]

I'll chime in here, it can happen on stock consoles and modded ones and everything inbetween

[ramapcsx2]

Yeah, sure. We need to understand the problem first, a fix can be devised then :p
I'm trying a couple consoles with my devkitC dongle, but so far no "luck".

[darthcloud]

Will sent me one of those mobo, will look into it when I receive it.

[Batossai84]

I have the same problem. pu-18 with ps1digital and xstation installed. I tried 2 different unoretro. One with the original firmware and another with 1.1. They behave the same way, random button inputs and I could not use a bluetooth mouse either.

[marceloMedeiros]

I have the same problem. pu-18 with ps1digital and xstation installed. I tried 2 different unoretro. One with the original firmware and another with 1.1. They behave the same way, random button inputs and I could not use a bluetooth mouse either.

Since i also have a pu18 with ps1digital and xstation and blueretro seems to be working fine on my end, maybe we can figure out whats causing the problem if we compare our setups and use case. In my case, in addition to the aforementioned, my ps1 also has a willconsolemods psu replacement, and im using a nice 12v 5a psu with it.

Can you describe what is your setup exactly? And the steps to reproduce the erractic behavior (i.e. ,what games you are running, etc)

[dryja123]

I have the same problem. pu-18 with ps1digital and xstation installed. I tried 2 different unoretro. One with the original firmware and another with 1.1. They behave the same way, random button inputs and I could not use a bluetooth mouse either.

Since i also have a pu18 with ps1digital and xstation and blueretro seems to be working fine on my end, maybe we can figure out whats causing the problem if we compare our setups and use case. In my case, in addition to the aforementioned, my ps1 also has a willconsolemods psu replacement, and im using a nice 12v 5a psu with it.

Can you describe what is your setup exactly? And the steps to reproduce the erractic behavior (i.e. ,what games you are running, etc)

When I was speaking to Will about the issue, he was saying that there are different board revisions of the PU-18. In my case I have a PU-18 1-644-537-52. Can you confirm that you have the same PU-18 revision?

For me, the issue happens as soon as I insert the PSUnoRetro. It's not game specific, even happens at the memory card manager screen. As soon as you plug the device in it just starts spamming inputs.

If you could provide your PU-18 revision that would be extremely helpful, since you're not having the issue.

[Batossai84]

Eur 5502 PU-18 1-664-537-52 serial C5578908 (will psu, will igr, ps1digital, xstation) there are lot of random button inputs.
Usa 5501 PU-18 serial U7559134 (psio) there are less random inputs, but they still exist. Pressing start or if you pulse and mantain a button it is pressed again after some time, while this doesn’t happen on a regular controller.
Eur 7502 pu-20 (psio) everything seems to work fine.
Sorry for not sharing the board of the usa, but I would have to unscrew too many things and I don't have time to do it.
edit: I´m sorry, I rechecked the image of my installation and it is the same as marceloMadeiros. I didn´t write it right before.

[marceloMedeiros]

I have the same problem. pu-18 with ps1digital and xstation installed. I tried 2 different unoretro. One with the original firmware and another with 1.1. They behave the same way, random button inputs and I could not use a bluetooth mouse either.

Since i also have a pu18 with ps1digital and xstation and blueretro seems to be working fine on my end, maybe we can figure out whats causing the problem if we compare our setups and use case. In my case, in addition to the aforementioned, my ps1 also has a willconsolemods psu replacement, and im using a nice 12v 5a psu with it.
Can you describe what is your setup exactly? And the steps to reproduce the erractic behavior (i.e. ,what games you are running, etc)

When I was speaking to Will about the issue, he was saying that there are different board revisions of the PU-18. In my case I have a PU-18 1-644-537-52. Can you confirm that you have the same PU-18 revision?

For me, the issue happens as soon as I insert the PSUnoRetro. It's not game specific, even happens at the memory card manager screen. As soon as you plug the device in it just starts spamming inputs.

If you could provide your PU-18 revision that would be extremely helpful, since you're not having the issue.

I wasnt sure what exact revision mine was so had to crack it open. And yep, just confirmed and it seems to be the exact same revision.

Also forgot to mention that on top of everything i already mentioned, im also using a memcardPro.

Finally, i want to clarify that im using a reference Blueretro device, not the PSUnoRetro. And I use just one blueretro for both controllers (with a 2 player cable).

Im not sure if thats relevant or if the PSUnoRetro is the exact same thing or a custom device with different characteristics compared to the reference design. But i think it might be relevant...since our setup seems to be almost identical, except for the blueretro device itself.

[dryja123]

I have the same problem. pu-18 with ps1digital and xstation installed. I tried 2 different unoretro. One with the original firmware and another with 1.1. They behave the same way, random button inputs and I could not use a bluetooth mouse either.

Since i also have a pu18 with ps1digital and xstation and blueretro seems to be working fine on my end, maybe we can figure out whats causing the problem if we compare our setups and use case. In my case, in addition to the aforementioned, my ps1 also has a willconsolemods psu replacement, and im using a nice 12v 5a psu with it.
Can you describe what is your setup exactly? And the steps to reproduce the erractic behavior (i.e. ,what games you are running, etc)

When I was speaking to Will about the issue, he was saying that there are different board revisions of the PU-18. In my case I have a PU-18 1-644-537-52. Can you confirm that you have the same PU-18 revision?
For me, the issue happens as soon as I insert the PSUnoRetro. It's not game specific, even happens at the memory card manager screen. As soon as you plug the device in it just starts spamming inputs.
If you could provide your PU-18 revision that would be extremely helpful, since you're not having the issue.

I wasnt sure what exact revision mine was so had to crack it open. And yep, just confirmed and it seems to be the exact same revision.

Also forgot to mention that on top of everything i already mentioned, im also using a memcardPro.

Finally, i want to clarify that im using a reference Blueretro device, not the PSUnoRetro. And I use just one blueretro for both controllers (with a 2 player cable).

Im not sure if thats relevant or if the PSUnoRetro is the exact same thing or a custom device with different characteristics compared to the reference design. But i think it might be relevant...since our setup seems to be almost identical, except for the blueretro device itself.

Thanks for confirming. I am also using the PS1 Digital, xStation, and Memcard Pro.

[Batossai84]

[darthcloud]

Spend some big buck to get the exact same revision with pre-installed xstation. I tested with the PSUnoRetro Will gave me and I couldn't reproduce the issue.

I'll do more test over the weekend.

The PSU is original and no HDMI mod.

@dryja123 & @Batossai84 can you list all the mod your respective console have?

I assume you tested without the mem card pro to be sure?

Still waiting to receive Will's one and/or one of Will customer donation.

[darthcloud]

Re-reading the whole thread look like we can't really blame a particular mod mix. Will be easier to troubleshoot when I get the donation. I got a good PU-18 to compare with which is nice.

[dryja123]

I would love to let you borrow my console but I don’t trust shippers and with the current state of things. I wouldn’t be able to replace the mods if the console was lost.

I’m happy to test things for you. Just let me know.

[darthcloud]

@dryja123 & @Batossai84 I might have a fix but could not test since I didn't receive problematic board yet, but it's tested to work as before on my PSX. Could you give it a try and report back?
1.2.1_wip.zip

With my scope I was able to see some voltage fluctuation on data output:

This was due to GPIO not being properly configure as open drain. Not I got no fluctuation anymore:

I guess most console didn't care much about it but some where sensitive to that and would glitch sometimes.

[dryja123]

Hey @darthcloud I had an opportunity to flash this firmware. Unfortunately, it did not fix the issue for me. Now when the console turns on the device has a solid white light; indicating an error. I press the reset button (on the unoretro) and the light starts to blink, like it’s pairing. As soon as the light starts to blink it starts to spam button presses.

[darthcloud]

Did you use v1.2 before? So now at every power on the led stay solid, but original 1.2 didn't?

[Batossai84]

I´m busy working right now and I can´t run many test until the holidays are over. Whenever I could I will transplant the controller piece from the 7502 to the 5502 to check if it is a hardware problem there. The unoretro works fine on my 7502. Last time I updated it took 10 hours using my phone, so I can only update while sleeping. My pc doesn´t have the software to identify the unoretro when I connect it via usb.

[dryja123]

Did you use v1.2 before? So now at every power on the led stay solid, but original 1.2 didn't?

I used what ever version 0.19.1 and 1.1.1 and didn’t have the issue with the solid white light. I didn’t see the 1.2 release so this was the first time I used it.

[darthcloud]

@dryja123 when you connect to the adapter via OTA page do you see this line in the page log:
App version: v1.2-3-g0c51667 psx_ps2

If not the flashing failed. You selected the file BlueRetro_psx_ps2_spiffs.bin in the zip right?

[dryja123]

@darthcloud I didn’t entirely pay attention to what the log said. I did choose that file. I can flash it up again and I’ll pay closer attention to what the log says.

[darthcloud]

@dryja123 Like just connect to it and check the log, no need to reupload

[dryja123]

@darthcloud Just hopped on my PC and I left the webpage up from last night. This is the what the live output said:

Requesting Bluetooth Device...
Connecting to GATT Server...
Getting BlueRetro Service...
Get Api version CHRC...
Reading App version...
App version: v1.1.1 psx_ps2_spiffs
Init Cfg DOM...
FW upload done. Took: 314.32970000000296 sec

Bluetooth Device disconnected

Connected now:

Requesting Bluetooth Device...
Connecting to GATT Server...
Getting BlueRetro Service...
Get Api version CHRC...
Reading App version...
App version: v1.2-3-g0c51667 psx_ps2
Init Cfg DOM..

[darthcloud]

@dryja123 ok weird, mine don't have solid led, thanks for testing. I'll just wait to get the board from Will.

[darthcloud]

Email me to darthcloud gmail.com (replace space with @) or DM me on twitter, we can coordinate this way. I'll pay fedex/ DHL overnight both way.

[tajunk]

Fix: power direct from PS1 3.3v instead of 7v + regulator.

Thanks for this, but could you clarify a little more on what you did?
Is it just remove the third pin from the right, put it in the middle (just to be off the pad I'm assuming?) and wire it to the regulator?

Just wanted to clarify as I'm decent at soldering but the technical stuff escapes me somewhat lol.

[tajunk]

Fix: power direct from PS1 3.3v instead of 7v + regulator.

Thanks for this, but could you clarify a little more on what you did? Is it just remove the third pin from the right, put it in the middle (just to be off the pad I'm assuming?) and wire it to the regulator?
Just wanted to clarify as I'm decent at soldering but the technical stuff escapes me somewhat lol.

Reach out to Will’s Console Mods. He said he’s going to issue replacements to those who are having this issue.

That works too! Thank you

[tajunk]

Fix: power direct from PS1 3.3v instead of 7v + regulator.

Sorry to bump this again but: I've contacted Will a couple weeks ago now and didn't get a response so it looks like I'm going to have to attempt this fix myself.
Any chance I could get some clarification from @darthcloud @TerminatorSVT on what's happening here? Is it just changing the pin location from the third on the right to the middle and wiring it to that regulator or am I missing something? Thank you to anyone who could help!

[tajunk]

Thanks so much @TerminatorSVT !! Appreciate the explanation and clarification, I just did the fix and it's working perfect now on my ps1!

[darthcloud]

First off sorry for not actively working on this, but since I don't have HW to reproduce the issue and being now a new father made this important issue less attractive to work on vs adding new features.

Anyway someone suggested this is a BT power issue, so here a FW to try with BT completely off.
<FW removed>

This assume you can reproduce the glitch (random input) in the X-station menu without any BT device connected.
If you do, try this FW and the result will help determine if it related to power draw from the radio or not.

[TerminatorSVT]

No worries man haven't even played PS1 since then. The big issue with random button spam with nothing connected was resolved when moving the power source from 7v pin to 3.3v pin. Might still be issues with dropped inputs, hard to tell if its blueretro or just software blocking or polling interval. Eg hitting up / down too fast repeatedly.

…

On Wed, Apr 13, 2022, 6:47 AM Jacques Gagnon ***@***.***> wrote: First off sorry for not actively working on this, but since I don't have HW to reproduce the issue and being now a new father made this important issue less attractive to work on vs adding new features. Anyway someone suggested this is a BT power issue, so here a FW to try with BT completely off. v1.5.1_btoff.zip <https://github.com/darthcloud/BlueRetro/files/8481956/v1.5.1_btoff.zip> This assume you can reproduce the glitch (random input) in the X-station menu without any BT device connected. If you do, try this FW and the result will help determine if it related to power draw from the radio or not. — Reply to this email directly, view it on GitHub <#102 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXH7BFB7RZVYO6FDKWQ7O7DVE3F63ANCNFSM5I7TETHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[darthcloud]

Another suggestion is to place inline 220 ohm resistor between ESP32 inputs and PS pin 2 (TXD aka CMD), pin 6 (DTR aka CS) and pin 7 (SCK). Original controllers got those maybe for a reason!

[dryja123]

I received the latest revision of the PSUnoRetro from Will, with the 3.3v change, and the replacement unit is exhibiting the same behavior.

[darthcloud]

ok cool, I think Will will send you another dongle with those resistor too.

[darthcloud]

@dryja123 if you use extension keep the cord between the dongle and console less than 1 feet. Long extension made problems for other people.

[darthcloud]

I added the resistor this morning, work fine as before on my PU-18. I took 249 ohm resistors as this is what I had on hand.

[dryja123]

@darthcloud soldered up the 3 220ohm resistors and I’m still getting random inputs. It doesn’t seem as bad, but it’s still happening. Just a note, pin 3 does look close to the pins on the ESP but there’s plenty of clearance and it’s not shorting.

[dryja123]

I wish I could send you the console for debugging but the PS1D is impossible to get. I’d be crushed if the console got lost in transit.

[darthcloud]

Thanks for taking time to test it.

I think this will ultimately need more serious analysis with a scope on a system with the issue.

The best would be if someone was willing to sell me one.

[darthcloud]

@dryja123 from what I understand you see random input right away in the xstation menu, right? (no need to connect BT controller).

If it's not too much to ask could you try the no BT FW for BlueRetro?
<FW removed>

This will keep the radio off and would help to tell if the issue is due to power draw spike due to RF TX.

[dryja123]

@darthcloud right away in the xStation menu and also the system BIOS. If I flash that BT off firmware how do I flash firmware in the future? Would I need to buy a hardware flasher?

I have an ESP dev kit. I might just flash that up and see if it produces the same issue. If it does, I can then just flash normal firmware over USB

[darthcloud]

oh yeah I didn't think about this!

Yeah try with the devkit if you can, try first with regular FW to see if you reproduce, then use the no BT FW.

[darthcloud]

@dryja123 actually holding the boot button 10 sec to factory reset would revert to the original FW the unoretro got ship with.

[dryja123]

@darthcloud flashed up the BT off firmware and the random button presses are gone. I was unable to revert back to factory firmware by following the factory reset procedure. That's ok, I'll get a programmer and program the device over USB. I'm still going to tinker around with the dev kit this weekend too.

[darthcloud]

ha crap sorry, I forgot the button task is started by the BT task :S. I'll make a couple FW tonight with different TX power setting.

[dryja123]

Awesome, I can test it out on the dev kit. I’ll start with the latest stable firmware to duplicate the issue. I’ll flash up the test ones you send.

[darthcloud]

Here builds for 3dbm, 0dbm, -3dbm, -6dbm, -9dbm and -12dbm
v1.5.1_psx_bt_pwr.zip

3dbm is what was used in previous FW.

[dryja123]

I was able to flash up to -6dbm before I wasn’t able to the adapter anymore. It wasn’t even coming up when I was scanning for Bluetooth devices with my phone, with the phone next to the adapter.

[darthcloud]

You can factory reset with those build. So did 0dbm or -3dbm had random input?

[dryja123]

No, didn’t factory reset with those builds. I flashed up the firmware, rebooted the consoles, and tested. I had random inputs on everything I tested. Stock 3dbm, 0dbm, -3dbm, -6dbm. Wasn’t able to test further.

[darthcloud]

if you disconnect 8v or 3.3v from PS and instead power externaly via usb?

Does that work?

[dryja123]

I’ll give that a shot and report back.

[dryja123]

This is a fantastic work and a great amount of information. I have the original kit, the kit with the 3.3v power, and a ESP32 dev kit. I’m a paint by numbers kind of guy and can hook what ever you suggest up to a breadboard and test; just let me know what I need to get.

I’ll still test powering the unit off of external power.

[darthcloud]

8bitmods guy say to try:

• CLK: 100 Ohm
• ACK: 22 Ohm
• DATA (RX): 22 Ohm
• CMD (TX): 220 Ohm
• ATT (CS): 220 Ohm

[dryja123]

Awesome, I have all of those except for the 22ohm resistors, I have 20. I’m sure the extra 2ohms won’t make a difference but if it doesn’t work I’ll buy some.

[darthcloud]

20 is fine

[williamgentry12]

@dryja123 Can't wait to hear about the results using the resistors 👍

[dryja123]

@williamgentry12 is there any way you could share the pinout on your adapter to make it easier for me to test? You can share via discord DM, if that works easier for you.

[williamgentry12]

[dryja123]

Thank you!

[darthcloud]

One experiment a did this weekend is to simply add 220uF cap on the LDO 8V input, this reduced the ripple from 700mV to around 100mV. Might be worth a try.

[Z3R0XZ]

Oh, I have the same issue with my PS1 PU-18 and Xstation, even with external power for the BlueRetro module the problem persists, random inputs everywhere.

[darthcloud]

@dryja123 keep us updated, I can cover cost of next day express shipping with full insurance no problem myself.

[jon-nielsen]

Lots of good information in this thread. I have a 5502 with the same issue. Will try some of the fixes mentioned here 👌

[dryja123]

Lots of good information in this thread. I have a 5502 with the same issue. Will try some of the fixes mentioned here 👌

I just shipped my console off to darthcloud, so I'm hoping we see a resolution!

[dryja123]

Just also updated the title of this ticket. I accidently had a typo in my sub revision. My actual board is PU-18 rev. 1-644-537-62

I have a few friends who have 1-644-537-42 and 52 that are fine.

Edit: Pay me no mind today, I had a few consoles that I did installs on and got my photos mixed up. The one I'm sending in ends in 52.

[jon-nielsen]

I've gotten another 5502 now as the other one had too many issues. Recapped its PSU, installed X-Station. It doesn't have constant spamming of wrong input as soon as the dongle is connected, but it did happen once during testing. So I'll try the 220uF cap fix on 8V first, before switching power source or adding resistors to the lines.

[darthcloud]

I got @dryja123 console today, reproduced issue and troubleshooted a little bit software side.

First Bluetooth isn't a factor in this console problem, I left the radio completely off and I still get the random input.

When the issue occur what BlueRetro receive on SPI from PS1 is garbage/corrupted.

I'll setup the scope next and will take a look at the signal shape when this happen.

[dryja123]

Thank you!

[jon-nielsen]

For what it's worth, I've not had any issues since switching to a new 5502 (and recapping its PSU as well as adding 220uF to 8v). But reading the latest findings, this may just be random.

[darthcloud]

Weekend update

Let's start with what is working:
Unplugging the PS1 Digital controller flex resolve the random input issue.
I still get random reading from the bus when the console is "cold" but once it ran for a 1min or I do power cycle after that I don't see random read. I any case when I get the random read, no random press occur when PS1 digital controller flex is unplug.

What change nothing while PS1 digital controller flex is connected:
Using my PS1 PSU in @dryja123 console
Powering BlueRetro externaly
Any combination of ESP32 SPI timing setting other than what is currently used (make things worst)
Any combination of ESP32 SPI timing using the 8bitmod resistor recommendation.

I think I'm done with it on my side unless someone got ideas.

I will not troubleshoot this further as it is not my console, One thing to try for someone with that issue and a PS1 digital that feel adventurous:
Maybe the PS1D inputs put some load on the line somehow, maybe try to put a buffer in between the PS connector and the PS1D like a 74ahct125.

[dryja123]

I reached out to citrus3000psi (one of the creators of the PS1 Digital) and he said he’s going to take the console in for review. He’s going away on vacation next week so DarthCloud is going to send me the console back and I’ll forward along when citrus3000psi returns.

[ramapcsx2]

Okay, great. With scope in hand, I'm sure you've experimented around a bit :p
I found that some combinations have the same timing relations on the scope, but affect other factors.
What happens on the 2 data lines outside of valid data, for example.

It's kind of possible that your manual config is not working around a hardware bug, particularly if DMA is used, and extra particularly if DMA + SPI slave mode is used.
But on the other hand, since it IS working on most machines and dongles, this is unlikely, probably :p

So hmm, out of ideas for now.

[darthcloud]

I'm not using DMA, I get an interrupt every single byte and load a single byte per interrupt.

This is to be able to pulse the ACK line but also to allow for some logic base on on data coming from PS, like the multitap enable bit etc.

[darthcloud]

Thinking about it now, the only thing I haven't try is to use the dedicated/native SPI pins.

That would bypass the ESP GPIO matrix and might change the timing significantly maybe?

[ramapcsx2]

It's a significant change to internal timings.
Right now, you can modify the peripheral subtimings, but have little control over the GPIO matrix switch delays.
I'm quite confident that the GPIO matrix doesn't skew any timings in relation to each other (unless you use the inversion, possibly), so overal, at PSX SPI speeds, it shouldn't affect the problem.. But who knows :p

Edit:
Took a peek at the pins used. Of the high IO that don't have pullups, only IO34 is used, right? P1_DTR_PIN ?
Shouldn't matter then.

[darthcloud]

I wonder if there could be a different delay between the lower GPIO bank and the upper one, All input are on the upper bank (IO32, 33, 34) and output on the lower bank (19, 21).

Cause the upper bank are also the ADC inputs so the internal circuitry of the pin is likely different than the others.

[darthcloud]

I'll make some FWs later using the native pins, and variation of perif ctrl2 timing like current one + 4 official SPI slave non-DMA timing.

[ramapcsx2]

Hm, people would have to rewire their dongles and such. A bit tricky :p
But what may the condition be that triggers it on certain consoles only? Does it require a ps1digital attached, and do these special consoles have different passives on the SPI bus by chance?

[darthcloud]

I think it's likely that their is more than one cause at play.

This will be for handy people to test using devkitc. I bet it wont help but worth trying.

If it help then I guess we can figure the logistic, likely use a fuse to identify adapter that use new pins.

[Z3R0XZ]

Hm, people would have to rewire their dongles and such. A bit tricky :p But what may the condition be that triggers it on certain consoles only? Does it require a ps1digital attached, and do these special consoles have different passives on the SPI bus by chance?

I don't have PSDigital only an XStation, before installing the XStation the ESP32 module was working fine.

[darthcloud]

@Z3R0XZ By ESP32 module you mean BlueRetro? You started seeing random press after an Xstation install?