PS3 Fault finding YLOD with the SYSCON - First steps and Error reporting

doragasu said:
+1.8v_RSX_PLL_VDD (JL6048) - Test after inductor:
View attachment 26638


+1.2V_RSX_VDDC (NEC-Tokin): Tested before: tries rising about 100 mV and then goes down

+1.2V_RSX_VDDR (JL9651):
View attachment 26642

+1.2V_YC_RC_VDDIO (JL9652)
View attachment 26639

+1.5V_RSX_VDDIO (JL9656)
View attachment 26640

+1.8V_RSX_FBVQQD (JL9657)
View attachment 26641

Excepting the voltage in the NEC/TOKINs, everything looks OK to me.
Click to expand...

They are ok, except +1.2V_RSX_VDDC (NEC-Tokin)

Can you measure IC6201 (page 25) pins 1,2,3,30,31 and 32, they form a binary voltage comparison code. Is pin 29 in high level?
 
I tested all the values in the COK-002 test point list. 2-3 pads were in a slightly different position on the COK-001, and the only one I wasn't able to find a match for was JX9602. Still, though, everything I was able to check had the correct values from the list! But I'm still getting 3034...

Out of everything so far, I'm still getting 0v out of pin 1 on both IC6022 (JL6070) and IC6021 (JL6069). It was suggested that lack of voltage might be related to IC6011, and I am getting 2.6 out of pin 5 (VO), so it's probably further down the line...
 
Last edited:
just my luck... I shorted 17 and 18 on IC6003, and fried C6025... Testing that cap on the board gives me 0 ohms.

At least we get to add a few more error codes to the list.

The initial "bump" on 17-18 (The slip was during boot), and it triggered the following errors:
401001 - BE VRAM Power Fail
402120 - HDMI Error (IC2502)
401301 - BE PLL Unlick
Since all these errors are in the same step, I'm guessing they were triggered at the same time. I wasn't connected to syscon right then, unfortunately.

The second attempt, same pins during boot, only triggers 1 error, with a fast ylod
022110 - Clock Generator Error (IC5001).

Here's the full errlog (no time stamps on my board, somehow, I just never have them)
Code: 
errlog
ofst[ 20]:err_code:0xffffffff, clock:0xffffffff
ofst[ 24]:err_code:0xa0403034, clock:0xffffffff
ofst[ 28]:err_code:0xa0403034, clock:0xffffffff
ofst[ 32]:err_code:0xa0403034, clock:0xffffffff
ofst[ 36]:err_code:0xa0403034, clock:0xffffffff
ofst[ 40]:err_code:0xa0403034, clock:0xffffffff
ofst[ 44]:err_code:0xa0403034, clock:0xffffffff
ofst[ 48]:err_code:0xa0403034, clock:0xffffffff
ofst[ 52]:err_code:0xa0403034, clock:0xffffffff
ofst[ 56]:err_code:0xa0403034, clock:0xffffffff
ofst[ 60]:err_code:0xa0403034, clock:0xffffffff
ofst[ 64]:err_code:0xa0403034, clock:0xffffffff
ofst[ 68]:err_code:0xa0403034, clock:0xffffffff
ofst[ 72]:err_code:0xa0403034, clock:0xffffffff
ofst[ 76]:err_code:0xa0403034, clock:0xffffffff
ofst[ 80]:err_code:0xa0403034, clock:0xffffffff
ofst[ 84]:err_code:0xa0403034, clock:0xffffffff
ofst[ 88]:err_code:0xa0403034, clock:0xffffffff
ofst[ 92]:err_code:0xa0403034, clock:0xffffffff
ofst[ 96]:err_code:0xa0401001, clock:0xffffffff
ofst[100]:err_code:0xa0402120, clock:0xffffffff
ofst[104]:err_code:0xa0401301, clock:0xffffffff
ofst[108]:err_code:0xa0403034, clock:0xffffffff
ofst[112]:err_code:0xa0022110, clock:0xffffffff
ofst[116]:err_code:0xa0022110, clock:0xffffffff
ofst[120]:err_code:0xa0022110, clock:0xffffffff
ofst[124]:err_code:0xa0022110, clock:0xffffffff
ofst[  0]:err_code:0xa0022110, clock:0xffffffff
ofst[  4]:err_code:0xa0022110, clock:0xffffffff
ofst[  8]:err_code:0xa0022110, clock:0xffffffff
ofst[ 12]:err_code:0xa0022110, clock:0xffffffff
ofst[ 16]:err_code:0xa0022110, clock:0xffffffff

The relationship between IC6003 and IC5001 isn't super obvious to me. Pin 46 on IC5001 is labelled SCLK, that's my best guess, but nothing else stands out to me. I mean, there's a good chance i just fried IC6003 altogether (pins 17, 18, 19 and 21 are all dead), but for now I'm hoping that replacing that tiny cap (0.1uf??) will bring things back to its previous state. Hopefully I have one in the scrap pile.
 
marciolsf said:
I mean, there's a good chance i just fried IC6003 altogether (pins 17, 18, 19 and 21 are all dead), but for now I'm hoping that replacing that tiny cap (0.1uf??) will bring things back to its previous state. Hopefully I have one in the scrap pile.
Click to expand...

I will see it for you tonight.
 
Only RSX can cause GLOD(Green Light)? This problem could be in CELL or an error in process correction in eeprom checksum?

My third PS3 repaired from error 1002 have a GLOD. I do this: I turn on, wait 3 minutes and reset, PS3 boots normally without artefacts. I'm very sad because this PS3 hadn't GLOD before YLOD, it worked normally.

My other 2 PS3 repaired from error 1002 have a new error 3034 and worked after pressure on board. They worked normally before Ylod too.

All these PS3 repaired with error 1002 had problem with BGA after change NEc by tamtalums. It could be NEc-Tokin removal process which danified something on board? I use cold removal and the board sits on CELL/RSX heatsink and on bottom metal plate. Or it was coincidence and the BGA problems decided to appear now on this 3 devices?
 
my 3rd YLOD.
I didnt connect BT module and BD. Only Power Supply.

Code: 
>$ bringup
bringup
[SSM] state: 0000 -> 0101
Bringup Mode #0 (0xFF)
[SSM] ssmCb_OnStartingBePowOn() called.
[SSM] Bringup mode : syspm_stat=00000000/00000000
[POWSEQ] PowerSeq_Setup called.
[SSM] state: 0101 -> 0201
[POWSEQ] AV Backend Setup
[SSM] state: 0201 -> 0102



>$ errlog
[SSM] state: 0102 -> 0202
[SSM] state: 0202 -> 0103
[SSM] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
[SSM] state: 0203 -> 0104
Psbd_SbTransMode_Half:0x20e7
[POWERSEQ] Error : BitTraining BE:RRAC:RX1:GLOBAL1:RX_STATUS
[SSM] state: 0104 -> 0304
[SSM] ssmCb_AfterBeOn2() called.
[SSM] PowSeq Fail : Detected !
[SSM] state: 0304 -> 0700
[POWSEQ] AV Backend Letup
[SSM] Shutdown mode : syspm_stat=00000000/00000000
[ERROR]: 0xa0404411
[ERROR]: 0xa0403034
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)
errlog
ofst[ 16]:err_code:0xffffffff, clock:0x267e666b  2020/06/18 17:52:43
ofst[ 20]:err_code:0xa0071002, clock:0x267e66f1  2020/06/18 17:54:57
ofst[ 24]:err_code:0xa0093004, clock:0x267e66f1  2020/06/18 17:54:57
ofst[ 28]:err_code:0xa0071002, clock:0x267e66fb  2020/06/18 17:55:07
ofst[ 32]:err_code:0xa0801002, clock:0x267e6825  2020/06/18 18:00:05
ofst[ 36]:err_code:0xa0801002, clock:0x267e682b  2020/06/18 18:00:11
ofst[ 40]:err_code:0xa0801001, clock:0x267e6871  2020/06/18 18:01:21
ofst[ 44]:err_code:0xa0801001, clock:0x267e701f  2020/06/18 18:34:07
ofst[ 48]:err_code:0xa0801001, clock:0x267e7038  2020/06/18 18:34:32
ofst[ 52]:err_code:0xa0801001, clock:0x267e70dd  2020/06/18 18:37:17
ofst[ 56]:err_code:0xa0801001, clock:0x267e7104  2020/06/18 18:37:56
ofst[ 60]:err_code:0xa0801001, clock:0x267e7136  2020/06/18 18:38:46
ofst[ 64]:err_code:0xa0801001, clock:0x26865afa  2020/06/24 18:42:02
ofst[ 68]:err_code:0xa0801001, clock:0x26865b3d  2020/06/24 18:43:09
ofst[ 72]:err_code:0xa0801001, clock:0x26865c2d  2020/06/24 18:47:09
ofst[ 76]:err_code:0xa0801001, clock:0x26865cda  2020/06/24 18:50:02
ofst[ 80]:err_code:0xa0801001, clock:0x2694c781  2020/07/05 17:16:49
ofst[ 84]:err_code:0xa0801001, clock:0x2694c7b2  2020/07/05 17:17:38
ofst[ 88]:err_code:0xa0404401, clock:0x2694d560  2020/07/05 18:16:00
ofst[ 92]:err_code:0xa0403034, clock:0x2694d560  2020/07/05 18:16:00
ofst[ 96]:err_code:0xa0404401, clock:0x2694d57b  2020/07/05 18:16:27
ofst[100]:err_code:0xa0403034, clock:0x2694d57b  2020/07/05 18:16:27
ofst[104]:err_code:0xa0404402, clock:0x2694d58d  2020/07/05 18:16:45
ofst[108]:err_code:0xa0403034, clock:0x2694d58e  2020/07/05 18:16:46
ofst[112]:err_code:0xa0404401, clock:0x2694d5a9  2020/07/05 18:17:13
ofst[116]:err_code:0xa0403034, clock:0x2694d5a9  2020/07/05 18:17:13
ofst[120]:err_code:0xa0404411, clock:0x2694d5c7  2020/07/05 18:17:43
ofst[124]:err_code:0xa0403034, clock:0x2694d5c7  2020/07/05 18:17:43
ofst[  0]:err_code:0xa0404401, clock:0x2694d671  2020/07/05 18:20:33
ofst[  4]:err_code:0xa0403034, clock:0x2694d671  2020/07/05 18:20:33
ofst[  8]:err_code:0xa0404411, clock:0x2694d722  2020/07/05 18:23:30
ofst[ 12]:err_code:0xa0403034, clock:0x2694d722  2020/07/05 18:23:30

UPDATE: after pressing on CELL and RSX:

Code: 
errlog
ofst[ 52]:err_code:0xffffffff, clock:0x2694de04  2020/07/05 18:52:52
ofst[ 56]:err_code:0xa0403034, clock:0x2694de04  2020/07/05 18:52:52
ofst[ 60]:err_code:0xa0404002, clock:0x2694de0f  2020/07/05 18:53:03
ofst[ 64]:err_code:0xa0403034, clock:0x2694de0f  2020/07/05 18:53:03
ofst[ 68]:err_code:0xa0801002, clock:0x2694de15  2020/07/05 18:53:09
ofst[ 72]:err_code:0xa0301002, clock:0x2694de1a  2020/07/05 18:53:14
ofst[ 76]:err_code:0xa0404002, clock:0x2694de1a  2020/07/05 18:53:14
ofst[ 80]:err_code:0xa0403034, clock:0x2694de1a  2020/07/05 18:53:14
ofst[ 84]:err_code:0xa0801002, clock:0x2694de1e  2020/07/05 18:53:18
ofst[ 88]:err_code:0xa0801701, clock:0x2694de27  2020/07/05 18:53:27
ofst[ 92]:err_code:0xa0901002, clock:0x2694de27  2020/07/05 18:53:27
ofst[ 96]:err_cod

>$ bringup
bringup
[SSM] state: 0000 -> 0101
Bringup Mode #0 (0xFF)
[SSM] ssmCb_OnStartingBePowOn() called.
[SSM] First Boot.
[SSM] Bringup mode : syspm_stat=00000000/00000000
[POWSEQ] PowerSeq_Setup called.
[SSM] state: 0101 -> 0201
[POWSEQ] AV Backend Setup
[SSM] state: 0201 -> 0102
 
Last edited:
LSL said:
12v→10v→12v?

I will see this variation on one of my boards. I think it should be stabilized 12v and not have this drop to 10v
Click to expand...
Yes, unfortunately I think I will not be able to test it again until weekend, but then I will try getting that on the scope. I am wondering if there might be a short somewhere causing that voltage drop when RSX voltage is enabled. Could it be RSX itself that is damaged? Also, if there is a short, should it blow a fuse? Or maybe thermal fuses auto-recover from this situation?
 
doragasu said:
Yes, unfortunately I think I will not be able to test it again until weekend, but then I will try getting that on the scope. I am wondering if there might be a short somewhere causing that voltage drop when RSX voltage is enabled. Could it be RSX itself that is damaged? Also, if there is a short, should it blow a fuse? Or maybe thermal fuses auto-recover from this situation?
Click to expand...
One of the things we'd been working on is document a number of contact points around RSX that we can use to test it's health. I'm not sure if that's testing solder joints to RSX, or RSX internals, though. If you want to try this, here's the original document that @db260179 posted

kSwyt11.jpg
 
marciolsf said:
One of the things we'd been working on is document a number of contact points around RSX that we can use to test it's health. I'm not sure if that's testing solder joints to RSX, or RSX internals, though. If you want to try this, here's the original document that @db260179 posted

kSwyt11.jpg
Click to expand...

It would be better to put which board model this picture belongs because the measurements may change, for example the COK-001 and Cok-002 boards do not have that 12.5 Ohm value in the upper left corner and neither have a CR2032 battery next to the RSX.
 
LSL said:
It would be better to put which board model this picture belongs because the measurements may change, for example the COK-001 and Cok-002 boards do not have that 12.5 Ohm value in the upper left corner and neither have a CR2032 battery next to the RSX.
Click to expand...
Ooh... that's a very good point. I'd guess the readings would be mostly the same for a 90nm chip, but then the locations might be different too. I can only speak for my cok-001, but my board is not working so i wouldn't take my numbers as reference.
 
You basically have two faults here,

Poor BGA connection - A full board reflow would fix this
VRAM faults for both RSX and CELL - no around this im afraid, you need a replacement RSX and RAM near the CELL

Without parts you will be going around in circles.

inazuma-akai said:
my 3rd YLOD.
I didnt connect BT module and BD. Only Power Supply.


UPDATE: after pressing on CELL and RSX:

Code: 
errlog
ofst[ 52]:err_code:0xffffffff, clock:0x2694de04  2020/07/05 18:52:52
ofst[ 56]:err_code:0xa0403034, clock:0x2694de04  2020/07/05 18:52:52
ofst[ 60]:err_code:0xa0404002, clock:0x2694de0f  2020/07/05 18:53:03
ofst[ 64]:err_code:0xa0403034, clock:0x2694de0f  2020/07/05 18:53:03
ofst[ 68]:err_code:0xa0801002, clock:0x2694de15  2020/07/05 18:53:09
ofst[ 72]:err_code:0xa0301002, clock:0x2694de1a  2020/07/05 18:53:14
ofst[ 76]:err_code:0xa0404002, clock:0x2694de1a  2020/07/05 18:53:14
ofst[ 80]:err_code:0xa0403034, clock:0x2694de1a  2020/07/05 18:53:14
ofst[ 84]:err_code:0xa0801002, clock:0x2694de1e  2020/07/05 18:53:18
ofst[ 88]:err_code:0xa0801701, clock:0x2694de27  2020/07/05 18:53:27
ofst[ 92]:err_code:0xa0901002, clock:0x2694de27  2020/07/05 18:53:27
ofst[ 96]:err_cod
Click to expand...
 
So these are reference ohms reading, 12.5ohm can be as low as 3.7ohms. The most crucial reading is the top right reading - it needs to be at least 100ohms, anything lower means faulty VRAM on the RSX chip - errors 1002 imply that issue

The remaining readings are just RSX core values and gives an idea the state of the RSX.

No readings means no connection or borked RSX chip - Reflow board and then check again.

Remember, 0.1 or 0.2 ohms means a short, this is a very possibility with RSX and CELL - I've fixed a couple of boards with this issue.

The RSX is a very sensitive to high heat and can be easily fried VRAM - My first endeavours I had killed so many RSX chips, this is the reason I know what to expect.

There is no way around this!

If you need to remove the RSX for a replacement, Buy a preheater or IR machine, dont use a hotgun you will fry the VRAM chips!

LSL said:
It would be better to put which board model this picture belongs because the measurements may change, for example the COK-001 and Cok-002 boards do not have that 12.5 Ohm value in the upper left corner and neither have a CR2032 battery next to the RSX.
Click to expand...
 
woot! I found my problem... I fried PS6001, the poor sucker is reading a resistance of 27MOhm. The spec is 2A/72V, but this is a "IC Link" type of component, which I'm having a bit of trouble finding a proper replacement for it. Can I use just a regular SMD fuse instead?
 
squeept said:
CELL/RSX voltages coming out of the TOKIN caps you need to set time axis to 1us and voltage axis to 50mv to see clearly. 5ms won't tell you anything. Check my signature for the reference images - I have the exact same scope.
Click to expand...
I repeated the measurements on the RSX, and same result: it goes up to about 100 mV, and then goes down.
 
LSL said:
They are ok, except +1.2V_RSX_VDDC (NEC-Tokin)

Can you measure IC6201 (page 25) pins 1,2,3,30,31 and 32, they form a binary voltage comparison code. Is pin 29 in high level?
Click to expand...

All measurements (excepting the last one, done with 100 mV time division, to see the full transition from power to shutdown).

Pin 1:
pin1.png


Pin 2, with 20 mV and 500 mV vertical scale:
pin2_500mV.png

pin2_20mV.png


Pin 3:
pin3.png


Pin 30:
pin30.png


Pin 31:
pin31.png


Pin 32 (with 500 mV and 20 mV vertical scale):
pin32_500mV.png

pin32_20mV.png


Pin 29:
pin29.png


And this is the 12V --> 10V -> 12V transition I see in pin 22:
pin22.png
 
You must log in or register to reply here.

Similar threads

Back
Top