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

Workz_777 said:
Hi @Kostaslgr7 ...i have 1 x spare (new) Teensy++ 2.0 if you want it, PM me if you are still wanting one.

View attachment 36324

I purchased 4 x Teensy++ 2.0 (~2 years ago) ...they are great for reading / writing to PS3 NAND/NOR. I followed @littlebalup TEENSY2PS3 guide. You would also need to buy a few more items to make it all work, see / download the guide / tutorial below.

Also see TEENSY2PS3 thread on psx-place here:-
https://www.psx-place.com/threads/teensy2ps3-pcb-linker-teensy-2-0-ps3.1728/

View attachment 36325
This TEENSY2PS3 PCB above, i purchased on eBay, but you can get it made by a PCB fab.
Gerber Files:- http://www.mediafire.com/download/fd8zqt1aykfi58p/TEENSY2PS3_v1.01.zip

Also, you might need to buy a TSOP-48 to DIP-48 - IC Socket (see photo below) instead of the "360-Clip". So you can desolder the NAND from the board and place it into the TSOP-48 to DIP-48 socket. Because for me the "360-Clip" didn't work very well, i couldn't get good contact to the NAND while it's still on the PS3 board.

View attachment 36327

But if you still want a "360-Clip" / "Wii-Clip" this is where i got mine one from:-
https://www.ic2005.com/shop/home.php?cat=16

Littlebalup TEENSY2PS3 Guide:-
http://www.mediafire.com/file/vg7410g3vo9w3dt/TEENSY2PS3_v1.01_manual_EN.pdf/file
Click to expand...
Hello, thank you for your offer, teensy2ps3 seems interesting I'll probably order pcbs of that.
 
CurieOS said:
I must have been unclear. The errlog I posted is from before I reflowed the thermal monitors and replaced the power/eject board. After I did that, I had the 12V prongs disconnected when I got that bringup log. Right now I'm at a GLOD state. I haven't grabbed a new syscon log since because I've been really busy.
Click to expand...
Ah, I see. Well now that you have the errorlog saved I'd suggest clearing the errorlog and this way you'll know what current errors appear (if any).

I'm in the same boat with a GLOD. You could measure the resistance around the RSX and CELL voltages...
cok-001_mb_ohm_test_points-jpg.36223

If they are all ballpark, then it's not a straitforward GLOD (bad VRAM = FBVDDQ short). Another common way is if RSX_VDDA or RSX_VDDIO go bad.

Given your hostory of reflows I would suspect a dead RSX VRAM. But the resistance on those voltage lines are useful to tell the story.

We're still collecting measurments and only have a few consoles worth. So if you want to record them and post here that would be helpful to the data collection effort. It may reveal the cause of your GLOD, or it might not. Mine looked ok and I still have the GLOD. So it's still mysterious.
 
RIP-Felix said:
We're still collecting measurments and only have a few consoles worth. So if you want to record them and post here that would be helpful to the data collection effort. It may reveal the cause of your GLOD, or it might not. Mine looked ok and I still have the GLOD. So it's still mysterious.
Click to expand...

I'll try to figure out a way to get all those measurements. There might be some equipment around my makerspace I can use to capture all those simultaneously. Might be a bit until I get that all. Thanks for the help though!! I appreciate all the work everyone here has done to keep these consoles running!
 
RIP-Felix said:
Given your hostory of reflows I would suspect a dead RSX VRAM. But the resistance on those voltage lines are useful to tell the story.
Click to expand...

Most ICs / SMDs, in their datasheets, say they can only be reflowed 3 times. So given the RSX/CELL were already reflowed once in production, means they can only be reballed / reflowed 2 more times before they start to degrade.
 
vyktormvmpay25 said:
Fuse 6301? 12 v line test for short/missing ? Hdmi area or short power for ic/dead ic. What errors were before attempting to fix this?
Also you have to log onto CXRF and clear errlog, run bringup up with unit semiassblbed and then post again errlog after power on.
Remember if rsx is not working should come first thing 3034 error and something 44xx.bad setup of modchip rsx always 4002.
Click to expand...

Finally got around to looking at this console. Here are the logs, fuse 6301 looks fine
ofst[ 28]:err_code:0xffffffff, clock:0xffffffff
ofst[ 32]:err_code:0xa0232102, clock:0xffffffff
ofst[ 36]:err_code:0xa0902120, clock:0xffffffff
ofst[ 40]:err_code:0xa0232102, clock:0xffffffff
ofst[ 44]:err_code:0xa0902120, clock:0xffffffff
ofst[ 48]:err_code:0xa0232102, clock:0xffffffff
ofst[ 52]:err_code:0xa0232102, clock:0xffffffff
ofst[ 56]:err_code:0xa0232102, clock:0xffffffff
ofst[ 60]:err_code:0xa0902120, clock:0xffffffff
ofst[ 64]:err_code:0xa0232102, clock:0xffffffff
ofst[ 68]:err_code:0xa0902120, clock:0xffffffff
ofst[ 72]:err_code:0xa0232102, clock:0xffffffff
ofst[ 76]:err_code:0xa0902120, clock:0xffffffff
ofst[ 80]:err_code:0xa0003001, clock:0xffffffff
ofst[ 84]:err_code:0xa0003001, clock:0xffffffff
ofst[ 88]:err_code:0xa0003001, clock:0xffffffff
ofst[ 92]:err_code:0xa0003001, clock:0xffffffff
ofst[ 96]:err_code:0xa0003001, clock:0xffffffff
ofst[100]:err_code:0xa0003001, clock:0xffffffff
ofst[104]:err_code:0xa0232102, clock:0xffffffff
ofst[108]:err_code:0xa0232102, clock:0xffffffff
ofst[112]:err_code:0xa0232102, clock:0xffffffff
ofst[116]:err_code:0xa0232102, clock:0xffffffff
ofst[120]:err_code:0xa0232102, clock:0xffffffff
ofst[124]:err_code:0xa0902120, clock:0xffffffff
ofst[ 0]:err_code:0xa0232102, clock:0xffffffff
ofst[ 4]:err_code:0xa0232102, clock:0xffffffff
ofst[ 8]:err_code:0xa0902120, clock:0xffffffff
ofst[ 12]:err_code:0xa0232102, clock:0xffffffff
ofst[ 16]:err_code:0xa0902120, clock:0xffffffff
ofst[ 20]:err_code:0xa0232102, clock:0xffffffff
ofst[ 24]:err_code:0xa0232102, clock:0xffffffff

[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
[SSM] state: 0102 -> 0202
[SSM] state: 0202 -> 0103
 
Seems rsx install didn't went well. Please follow videos of Computer Booter on YT. You may understand with time faults from your processes. Can't really know exactly each individual case.
I will consider from now good install of 40nm rsx to any older board 3034 followed by 4002 without orbis modchip . Even if we break orbis modchip this will be tested by syscon and repaired by patch in syscon boot without modchip.
 
@M4j0r @sandungas @RIP-Felix @ElGris @Pacorretaco @DeadEnd @David Rainer
I want some opinions after you guys watch those videos and explain what is wrong inside rsx , I know is faulty unstable one but how is that possible by hardware adding that.
So it was in the begin 5,4 ohms on vddc onboard ,pulled out of board rsx got 5,2 ohms ,after reball left 2 days, got 8 ohms no boot ,added that 2,2 ohms resistor and work!
http://s.go.ro/rxixxzkw
Also 4,4 ohms will drop to 2,7 ohms around .Still boot.Ill just desolder and left in cold enviroment like 20 another day to see if resistance is increased and work back without any parallel resistor.
 
Last edited:
vyktormvmpay25 said:
@M4j0r @sandungas @RIP-Felix @ElGris @Pacorretaco @DeadEnd @David Rainer
I want some opinions after you guys watch those videos and explain what is wrong inside rsx , I know is faulty unstable one but how is that possible by hardware adding that.
So it was in the begin 5,4 ohms on vddc onboard ,pulled out of board rsx got 5,2 ohms ,after reball left 2 days, got 8 ohms no boot ,added that 2,2 ohms resistor and work!
http://s.go.ro/rxixxzkw
Also 4,4 ohms will drop to 2,7 ohms around .Still boot.Ill just desolder and left in cold enviroment like 20 another day to see if resistance is increased and work back without any parallel resistor.
Click to expand...
Hmm, that's interesting yes...

But you know how unpredictable these kind of RSX problems are, even on slim yes?

Maybe if you remove the resistor it will still work? Ideally with a knife and no heat, repeating a couple times, because I don't really understand very well either...

Hopefully somebody else can explain better
 
On roon temperature at 25 Celsius is 5,4 ohms and still boot , after night was like 15 in room and increased that ic to 8 ohms. Well I just say those issues I've started to see often in slims. Is just rsx issues unstable, out should be maximum 3.2 ohms not 5.2.
 
Victor you find the weirdest issues and solutions.

I of course have no explanation, but that wont stop me from speculating.

The bodge resistor may be acting like those resistors we see next to the buck converter on early models. The 1st stage RC filter that tunes and multiplies the 2nd stage (tokins). However, I don't understand the slim VRM module as well as I do the Phats, since they changed it.

But I would suspect a discrete SMD resistor somewhere near the VRM controller or buck converter is wonky.

Otherwise, it could be the RSX itself. Cuz that VDDC off board resistance is unusually high. 3.2 ohms is the highest I've seen on the 6x "NOS" I've measured. Perhaps it's electromigration damage leading to an open fault. Not yet fully gone, but high enough resistance/impeedance to cause a GLOD.

Or perhaps those Vishay AlPol bulk filtering caps have gone bad? You could try replacing them real quick. Doubtful that's it, but it's not impossable.
 
No @RIP-Felix problem is not on this board, this is a defective rsx with 5,2 ohms out of board,I tested in another board as well kte001 same situation ,sorry i don't explain so well but i desoldered rsx and it was 5,2 out of board. I'm trying to explan that if we find something like this over 4,7 and board wont start ,we can add that resistance to simulate vddc as near condition of 3 ohms.We pull down so we can have load resistance in vddc for mosfet margins which i consider to be 2,7-to 4,7 in cold enviroment.
I think somehow it may trigger in series for 90nm another power resistance like 10w/1,5ohms to test.Just theory but ill order some 3 ohms /5w and add 2 in parallel may be 1,5ohms/10w in vddc after nec tokins are removed and we replace with tantal, we can test board after without desolde rsx.just theory for 90 nm need to wait parts.We increase or decrease vddc load resistance , I may test this theory asap as parts are here.
 
Last edited:
ok, so I hooked up my cecha01 again. I was having issues at first because I forgot I left it with internal mode enabled, so I was using the incorrect python parameters...

Then next I had to go lookup the commands, and wow, it's been a long time since I've last looked them up. The wiki has changed a lot! There's a ton of new info, that's awesome.

Anyway, here's some of my stats. I was surprised at my becount! I wonder how much of that was me just testing it over and over again over the last 2 years since it died

Code: 
>$ becount
becount
Bringup : 5644 times
Shutdown: 5604 times
Power-on: 351day 23hour 13min 15sec

And sure enough, my errlog is filled with these guys (don't mind the clock, the battery is unplugged)
>$ errlog
errlog
ofst[ 44]:err_code:0xffffffff, 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:0xa0403034, clock:0xffffffff
ofst[100]:err_code:0xa0403034, clock:0xffffffff
ofst[104]:err_code:0xa0403034, clock:0xffffffff
ofst[108]:err_code:0xa0403034, clock:0xffffffff
ofst[112]:err_code:0xa0403034, clock:0xffffffff
ofst[116]:err_code:0xa0403034, clock:0xffffffff
ofst[120]:err_code:0xa0403034, clock:0xffffffff
ofst[124]:err_code:0xa0403034, clock:0xffffffff
ofst[ 0]:err_code:0xa0403034, clock:0xffffffff
ofst[ 4]:err_code:0xa0403034, clock:0xffffffff
ofst[ 8]:err_code:0xa0403034, clock:0xffffffff
ofst[ 12]:err_code:0xa0403034, clock:0xffffffff
ofst[ 16]:err_code:0xa0403034, clock:0xffffffff
ofst[ 20]:err_code:0xa0403034, 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

While poking around and getting refamiliarized, I ran eepcsum, and was surprised at the errors I got

Code: 
>$ eepcsum
eepcsum
Addr:0x000032fe should be 0x52b7
Addr:0x000034fe should be 0x7115
Addr:0x000039fe should be 0x0f38
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff

I had to run the initial patch to enable internal mode, that's nothing new, but then we do fix it afterwards... I don't remember seeing these errors in the past. Is this to be expected? (and fixing them would then disable internal mode?). Bring up does work as expected
>$ bringup
[SSM] state: 0600 -> 0000
[SSM] Error state is cleared.
(PowerOff State)
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
[SSM] state: 0102 -> 0202
[SSM] state: 0202 -> 0103
[SSM] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
[SSM] state: 0203 -> 0104
Psbd_SbTransMode_Half:0x20e2
>$
[mullion]$ [POWERSEQ] Error : BitTraining BE:RRAC:RX0: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]: 0xa0403034
 
Also, happy to report that the powershell script works just fine, at least on a cok-001/mullion. I don't have my slim or superslim hooked up to test it, and the author says he hasn't had a chance to test it on SW syscons. Still, though, this should lower the difficulty for new users -- powershell comes on every windows box, and the script doesn't require any additional modules, it just works out of box.
 
marciolsf said:
ok, so I hooked up my cecha01 again. I was having issues at first because I forgot I left it with internal mode enabled, so I was using the incorrect python parameters...

Then next I had to go lookup the commands, and wow, it's been a long time since I've last looked them up. The wiki has changed a lot! There's a ton of new info, that's awesome.

Anyway, here's some of my stats. I was surprised at my becount! I wonder how much of that was me just testing it over and over again over the last 2 years since it died

Code: 
>$ becount
becount
Bringup : 5644 times
Shutdown: 5604 times
Power-on: 351day 23hour 13min 15sec

And sure enough, my errlog is filled with these guys (don't mind the clock, the battery is unplugged)
>$ errlog
errlog
ofst[ 44]:err_code:0xffffffff, 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:0xa0403034, clock:0xffffffff
ofst[100]:err_code:0xa0403034, clock:0xffffffff
ofst[104]:err_code:0xa0403034, clock:0xffffffff
ofst[108]:err_code:0xa0403034, clock:0xffffffff
ofst[112]:err_code:0xa0403034, clock:0xffffffff
ofst[116]:err_code:0xa0403034, clock:0xffffffff
ofst[120]:err_code:0xa0403034, clock:0xffffffff
ofst[124]:err_code:0xa0403034, clock:0xffffffff
ofst[ 0]:err_code:0xa0403034, clock:0xffffffff
ofst[ 4]:err_code:0xa0403034, clock:0xffffffff
ofst[ 8]:err_code:0xa0403034, clock:0xffffffff
ofst[ 12]:err_code:0xa0403034, clock:0xffffffff
ofst[ 16]:err_code:0xa0403034, clock:0xffffffff
ofst[ 20]:err_code:0xa0403034, 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

While poking around and getting refamiliarized, I ran eepcsum, and was surprised at the errors I got

Code: 
>$ eepcsum
eepcsum
Addr:0x000032fe should be 0x52b7
Addr:0x000034fe should be 0x7115
Addr:0x000039fe should be 0x0f38
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff

I had to run the initial patch to enable internal mode, that's nothing new, but then we do fix it afterwards... I don't remember seeing these errors in the past. Is this to be expected? (and fixing them would then disable internal mode?). Bring up does work as expected
>$ bringup
[SSM] state: 0600 -> 0000
[SSM] Error state is cleared.
(PowerOff State)
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
[SSM] state: 0102 -> 0202
[SSM] state: 0202 -> 0103
[SSM] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
[SSM] state: 0203 -> 0104
Psbd_SbTransMode_Half:0x20e2
>$
[mullion]$ [POWERSEQ] Error : BitTraining BE:RRAC:RX0: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]: 0xa0403034
Click to expand...
Well... There are your CPU BitTraining errors! (40 3034), all bunched up hehehe

marciolsf said:
I had to run the initial patch to enable internal mode, that's nothing new, but then we do fix it afterwards... I don't remember seeing these errors in the past. Is this to be expected? (and fixing them would then disable internal mode?). Bring up does work as expected
Click to expand...
Ahh, no need to worry about that. That is completely normal yes. Nothing to fix there, and internal (diag) mode will stay enabled without problems

Is it a 201GB syscon btw? Also you could try the commands
version
revision
 
Last edited:
marciolsf said:
While poking around and getting refamiliarized, I ran eepcsum, and was surprised at the errors I got

Code: 
>$ eepcsum
eepcsum
Addr:0x000032fe should be 0x52b7
Addr:0x000034fe should be 0x7115
Addr:0x000039fe should be 0x0f38
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff

I had to run the initial patch to enable internal mode, that's nothing new, but then we do fix it afterwards... I don't remember seeing these errors in the past. Is this to be expected? (and fixing them would then disable internal mode?)
Click to expand...
So there are no errors there. If there were an error you would see a sum line (sum:0xee10, or sum:0x0100 etc.) The line after the sum is the error. All the other ones don't matter. If there is no Sum, you don't have an error.
 
You must log in or register to reply here.

Similar threads

Back
Top