PS3 Fault finding YLOD with the SYSCON - First steps and Error reporting
marciolsf
Member
Woot!!!!
Thanks @db260179 for the fuse recommendation! I was able to change out PS6001, and now I'm back in business. Well, back to 3034, at least, which is where I was at, before I caused another short.
Notes on that situation -- I popped that particular fuse when I was probing IC6003 (pins 17 and 18, if you must know). After that sad event, I started getting error 2110, which maps out to Clock Generator Error (IC5001). I'd tested a number of the smaller ICs related to 5001, as well as a few of the other PWM ICs, and I found a common thread -- none of them were getting any power. It wasn't until I did a bit more studying on page 23 of the schematics that I went back found the true culprit -- a bad fuse. So IC5001 wasn't bad in and of itself, it just wasn't getting any power.
The conclusions here are two-fold -- first of all, don't do probing when you're tired and jittery from too many energy drinks, you will probably short something
. The other is one that we're all faimiliar with: an IC error doesn't necessarily mean that the chip itself is bad, only that it isn't working right. That can be from bad solder connections on the chip itself (which is what we think 3034 means), but also power supply to the chip.
Now that I can start testing again, there's a few things I'm going to start pursuing again:
* IC6022 and 6021 are not reporting any power out of their VOUT pins, but are getting power into VIN. I need to track that down (that's how I ended up shorting IC6003)
* I'd found some references on page 6 of the service manual that might help us understand the BitTraining errors from the bringup command, particularly the sections RRAC VCCIO BY PASSING and BE RRAC VDDA FILTER & BYPASS.
Thanks @db260179 for the fuse recommendation! I was able to change out PS6001, and now I'm back in business. Well, back to 3034, at least, which is where I was at, before I caused another short.
Notes on that situation -- I popped that particular fuse when I was probing IC6003 (pins 17 and 18, if you must know). After that sad event, I started getting error 2110, which maps out to Clock Generator Error (IC5001). I'd tested a number of the smaller ICs related to 5001, as well as a few of the other PWM ICs, and I found a common thread -- none of them were getting any power. It wasn't until I did a bit more studying on page 23 of the schematics that I went back found the true culprit -- a bad fuse. So IC5001 wasn't bad in and of itself, it just wasn't getting any power.
The conclusions here are two-fold -- first of all, don't do probing when you're tired and jittery from too many energy drinks, you will probably short something
. The other is one that we're all faimiliar with: an IC error doesn't necessarily mean that the chip itself is bad, only that it isn't working right. That can be from bad solder connections on the chip itself (which is what we think 3034 means), but also power supply to the chip.Now that I can start testing again, there's a few things I'm going to start pursuing again:
* IC6022 and 6021 are not reporting any power out of their VOUT pins, but are getting power into VIN. I need to track that down (that's how I ended up shorting IC6003)
* I'd found some references on page 6 of the service manual that might help us understand the BitTraining errors from the bringup command, particularly the sections RRAC VCCIO BY PASSING and BE RRAC VDDA FILTER & BYPASS.
db260179
Member
No problem, i've managed to track down some replacement parts as alternatives, but its getting hard now.
So your issue, had a quick look - its a cok-001?
So your errors link back to IC7301 which controls the sw_pci functions.
Hints are from RRAC VCCIO BY PASSING and BE RRAC VDDA FILTER messages, as this data issues, similiar to what the RSX gets on 4034.
Both of those IC6021 and 22 IC chips on pin 5 get enabled on IC7301 (CXD9208GP), so you could use a oscilloscope or just a voltage reading on those pins, a low voltage 0.307 would be bad. Track back to where they connect to and see if a rogue resistor or capacitor has failed or shorted?
Its possible the ic7301 has a bad BGA connection and just needs a reflow?
Keep us up to date, i've been adding errors against fixes and parts that need replacing on the first page of this thread.
So your issue, had a quick look - its a cok-001?
So your errors link back to IC7301 which controls the sw_pci functions.
Hints are from RRAC VCCIO BY PASSING and BE RRAC VDDA FILTER messages, as this data issues, similiar to what the RSX gets on 4034.
Both of those IC6021 and 22 IC chips on pin 5 get enabled on IC7301 (CXD9208GP), so you could use a oscilloscope or just a voltage reading on those pins, a low voltage 0.307 would be bad. Track back to where they connect to and see if a rogue resistor or capacitor has failed or shorted?
Its possible the ic7301 has a bad BGA connection and just needs a reflow?
Keep us up to date, i've been adding errors against fixes and parts that need replacing on the first page of this thread.
Woot!!!!
Thanks @db260179 for the fuse recommendation! I was able to change out PS6001, and now I'm back in business. Well, back to 3034, at least, which is where I was at, before I caused another short.
Notes on that situation -- I popped that particular fuse when I was probing IC6003 (pins 17 and 18, if you must know). After that sad event, I started getting error 2110, which maps out to Clock Generator Error (IC5001). I'd tested a number of the smaller ICs related to 5001, as well as a few of the other PWM ICs, and I found a common thread -- none of them were getting any power. It wasn't until I did a bit more studying on page 23 of the schematics that I went back found the true culprit -- a bad fuse. So IC5001 wasn't bad in and of itself, it just wasn't getting any power.
The conclusions here are two-fold -- first of all, don't do probing when you're tired and jittery from too many energy drinks, you will probably short something
Now that I can start testing again, there's a few things I'm going to start pursuing again:
* IC6022 and 6021 are not reporting any power out of their VOUT pins, but are getting power into VIN. I need to track that down (that's how I ended up shorting IC6003)
* I'd found some references on page 6 of the service manual that might help us understand the BitTraining errors from the bringup command, particularly the sections RRAC VCCIO BY PASSING and BE RRAC VDDA FILTER & BYPASS.
marciolsf
Member
Thanks for the hint on pin 5! Sure enough, they're dead. I'll work my way back from them and see where it's dying. I'm guessing it's going to be a common point...
marciolsf
Member
Alright, if I'm understanding the service manual correctly, pin 5 on 6021 and 6022 is tied to sw_pci. It took a bit to find out, but turns out sw_pci is tied directly to syscon (see page 17, Port I, pin L16). There's a single cap tied to that line (C6097), right next to the two ic's, but the line doesn't seem to go through the cap, so I don't know that it's relevant.
Hi
All
Really need some help
I am stuck
I have been searching for answers but no luck
I have completed the step starting with
EEP GET 3961 01
( I have followed all the steps and all is as it should be )
The guide says says turn of the ps3 and I done that
I then ground the diag pin to ground, as per guide
I have used the screw hole
and start following
Internal Command mode usage:
In the guide it says
PLEASE NOTE: The standby led will flash red repeatly and will not
turn on – This is normal as now we need to check the eeprom
checksum and fix it
When I ground the diag wire I get no red light and when I try to run the command
python ps3_syscon_uart_script.py COM6 CXRF
I keep getting
scopen response invalid
If I do not ground the diag the red light turns on and i can get into external mode
Please help
Many Thanks
My board the light does not turn on at all if i ground the diag wire
I still try to use the code
python ps3_syscon_uart_script.py COM5 CXRF But i receive error
scopen response invalid
All
Really need some help
I am stuck
I have been searching for answers but no luck
I have completed the step starting with
EEP GET 3961 01
( I have followed all the steps and all is as it should be )
The guide says says turn of the ps3 and I done that
I then ground the diag pin to ground, as per guide
I have used the screw hole
and start following
Internal Command mode usage:
In the guide it says
PLEASE NOTE: The standby led will flash red repeatly and will not
turn on – This is normal as now we need to check the eeprom
checksum and fix it
When I ground the diag wire I get no red light and when I try to run the command
python ps3_syscon_uart_script.py COM6 CXRF
I keep getting
scopen response invalid
If I do not ground the diag the red light turns on and i can get into external mode
Please help
Many Thanks
My board the light does not turn on at all if i ground the diag wire
I still try to use the code
python ps3_syscon_uart_script.py COM5 CXRF But i receive error
scopen response invalid
db260179
Member
Try and trace the exact pin these go back to that IC, and see if that IC on pin 1 has voltage, it could be dead?
On the sem-001 it is IC5001 it controls the pci bus, similiar or same on cok boards.
On the sem-001 it is IC5001 it controls the pci bus, similiar or same on cok boards.
nyislander
Member
This is my 1st attempt to "talk" to my PS3.
It's a CECHA (COK-001) board and a laptop with Xubuntu 18.04. I have everything properly connect (I think). I do have access to USB0. When the PS3 is turned on the led goes from solid red, a few seconds green (can't see yellow) then flashing red. After I execute the "python ps3_syscon_uart_script.py /dev/ttyUSB0 CXR" command I get no response. When I type "AUTH" at the prompt the response is "Auth1 response invalid".
Any/all help is appreciated.
It's a CECHA (COK-001) board and a laptop with Xubuntu 18.04. I have everything properly connect (I think). I do have access to USB0. When the PS3 is turned on the led goes from solid red, a few seconds green (can't see yellow) then flashing red. After I execute the "python ps3_syscon_uart_script.py /dev/ttyUSB0 CXR" command I get no response. When I type "AUTH" at the prompt the response is "Auth1 response invalid".
Any/all help is appreciated.
Turn on by rear power switch only, not by front power button. Led will goes to solid red and you execute the script on PC.
marciolsf
Member
I guess the good news of the day, after a couple of days of being super busy with IRL stuff, is that I finally got my ps3 under a high-quality scope... And my tantalum caps are bad! I wasn't able to get actual trigger captures, I had to make do with a slow motion video capture, but it's good enough to see it doesn't match @squeept 's baselines. I tested the caps beforehand, and I know they're good, so either the install is bad, or the bridge is bad, or the source into the caps is bad (?)
db260179
Member
As LSL has said, you dont need to take the ps3 out of standby, just flip the main power switch to on to bring up standby mode. Wait for a 10 or so seconds then try AUTH
Make sure the RX and TX are correct way around from ps3 board to ttl lead.
For the first step in external mode - just connect USB ttl lead RX,TX and GND to the ps3 board, leave the DIAG pin lead unconnected from the GND until you have done the change of diag mode in external command mode.
I've notice the quality of jumper cable affects the communication, try and use awg 30 cable, seems to work well.
Also make sure your are using python 2 and its modules are installed - serial and crypto
Make sure the RX and TX are correct way around from ps3 board to ttl lead.
For the first step in external mode - just connect USB ttl lead RX,TX and GND to the ps3 board, leave the DIAG pin lead unconnected from the GND until you have done the change of diag mode in external command mode.
I've notice the quality of jumper cable affects the communication, try and use awg 30 cable, seems to work well.
Also make sure your are using python 2 and its modules are installed - serial and crypto
nyislander
Member
Thank you LSL & db260179.
I've followed your recommendations and checked all connections but I'm still not able to "talk" to my PS3. I still get "Auth1 response invalid".
The ground wire was attached by removing a small portion of solder mask.
Is anyone else using Ubuntu & this USB to TTL v3.3 Serial Converter Cable?
I've followed your recommendations and checked all connections but I'm still not able to "talk" to my PS3. I still get "Auth1 response invalid".
The ground wire was attached by removing a small portion of solder mask.
Is anyone else using Ubuntu & this USB to TTL v3.3 Serial Converter Cable?
db260179
Member
Ok possible issue could be tx and rx are on the wrong way round.
To determine this, as you are using ubuntu, apt get install screen
Then in a shell - 'screen /dev/ttyUSB0 57600', turn off mains, then turn back on again, you should see something like 'OK', if nothing or cobbledgoop, then swap TX and RX around - this just confirms the serial is working.
If nothing on swap around then, poor connection or wire is too thick, make sure GND is from motherboard to uart lead.
And yes i use the same type lead, so no issues there.
Also, if serial is ok, remember to kill the screen program - 'pgrep screen | xargs kill -9'
When loading the python script, keep trying auth command, sometimes there is a delay when syscon loads on first power up
To determine this, as you are using ubuntu, apt get install screen
Then in a shell - 'screen /dev/ttyUSB0 57600', turn off mains, then turn back on again, you should see something like 'OK', if nothing or cobbledgoop, then swap TX and RX around - this just confirms the serial is working.
If nothing on swap around then, poor connection or wire is too thick, make sure GND is from motherboard to uart lead.
And yes i use the same type lead, so no issues there.
Also, if serial is ok, remember to kill the screen program - 'pgrep screen | xargs kill -9'
When loading the python script, keep trying auth command, sometimes there is a delay when syscon loads on first power up
Last edited:
Is AUTH (upper case) in CXR, is auth (lower case) in CXRF
Linux Terminal is case sensitive
nyislander
Member
Thank you db260179 & LSL.
First thing I tried worked - swapping TX and RX. Using AUTH/auth doesn't matter.
My PS3 mother board is a CECHA 1-871-868-32. To allow internal mode I changed:
>$ EEP GET 3961 01
00000000 FF
>$ EEP SET 3961 01 00
00000000
>$ EEP GET 3961 01
00000000 00
View attachment 27065
Then I grounded the "DIAG" pin, rebooted, fixed the checksum and listed the errors.
View attachment 27066
Error: 2110 Clock Generator Error (IC5001)
Guess I need to check around IC5001, bad components & VCC.
I also tried using "bringup" and the PS3 shutdown also immediately.
First thing I tried worked - swapping TX and RX. Using AUTH/auth doesn't matter.
My PS3 mother board is a CECHA 1-871-868-32. To allow internal mode I changed:
>$ EEP GET 3961 01
00000000 FF
>$ EEP SET 3961 01 00
00000000
>$ EEP GET 3961 01
00000000 00
View attachment 27065
Then I grounded the "DIAG" pin, rebooted, fixed the checksum and listed the errors.
View attachment 27066
Error: 2110 Clock Generator Error (IC5001)
Guess I need to check around IC5001, bad components & VCC.
I also tried using "bringup" and the PS3 shutdown also immediately.
marciolsf
Member
I believe I had the exact same error... Turns out the fuse PS something or other was out (there's only two on the board). I changed the higher value one, and that fixed the error for me.
Similar threads
-
-
PS3 CECHA00 with several SYSCON errors (3004, 1001,1002, 2120,3011)
- Started by LSL
- Replies: 7
-
PS3 Interesting PS3 Errors (1802, 1701, 1601) and Capacitor Replacement- Started by Cheshire UK
- Replies: 2
-