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

I hope someone will find this useful.
I have an A01 with 19 days of uptime that I delidded a few years ago. It was sitting on standby for months, and when I turned it on it had ylod. Thanks to everyone here, I was able to get the error form the Syscon.

3013 & 2120
F6302 wasn't blown, but I replaced the capacitors next to it and that cleared the errors.

1701 & 1200
When I first took the motherboard out I noticed a tiny smd between tokins and cell had fallen off and I reattached it. After I got 1701 I gave it a closer look and it didn't look like I reattached it properly, so I replaced it with another from a donor board. That cleared 1701, and the system booted.

I think I got 1200 because I powered it on without the fan plugged in or the heat sink attached. If you're going to boot for the purpose of throwing a new error, I strongly recommend those two things so you're not chasing your tail.

Best outcome for me though! I was able to repair it myself without heating up the cell and rsx, or replacing the tokins.

In my humble opinion, there's so much going on with these boards, everything should be checked before applying heat and causing permanent damage to something.
 
@TYRANT you can use the command "help" to display a long list with all the command names
I forgot your motherboard model, but if it have a sherwood syscon (with pins all around, not soldered by BGA) or in other words... a motherboard VER-001 or newer, they removed the clearerrorlog command

There is an aternative way to clear the error log just by writing zeroes to it, but this would be like a wayaround.. the weird thing is we dont know what to do to advise syscon that the battery has been replaced and it needs to use new timestamps. Maybe @M4j0r can throw some light to it ?

Ive seen at least a couple of persons in this forum reporting a working console that was throwing random syscon errors with weird timestamps after replacing the battery and after configuring the date/time in XMB syncing it with the store
I thought that was the only 2 requirements needed to "wakeup" the syscon timestamp counters
1) a working batery
2) sync the timestamps from syscon with the timestamps from gameOS

But it seems is not enought... something more is needed :(
 
Hey, so I have a CECHA01 PS3, it has YLOD. I've used the go to tutorials for this stuff, including the videos, especially by NSC modz, and I had issues with it because I don't know which model they have, and I've watched tons of other tutorials and they don't really say the model or anything, so I'm stuck not knowing where to connect the wires on my machine. Circled blue is TX and DX and black is ground. Also put a jumper between ground and the system board ground (copper edge of board). Set ft232r at 3.3v. Set to com3. During auth process it says "program error" , "unicode error", and never gives auth. Any help would be appreciated greatly.

X5dLGGR
 
Imo for user TYRANT rsx reflow /reball rsx problem. If reset image or pass to safe mode /recovery won't be possible still normal glod. Is still rsx imo.
 
Jordan561956193569 said:
Hey, so I have a CECHA01 PS3, it has YLOD. I've used the go to tutorials for this stuff, including the videos, especially by NSC modz, and I had issues with it because I don't know which model they have, and I've watched tons of other tutorials and they don't really say the model or anything, so I'm stuck not knowing where to connect the wires on my machine. Circled blue is TX and DX and black is ground. Also put a jumper between ground and the system board ground (copper edge of board). Set ft232r at 3.3v. Set to com3. During auth process it says "program error" , "unicode error", and never gives auth. Any help would be appreciated greatly.

X5dLGGR
Click to expand...
SYSCON Tutorial
 
Jordan561956193569 said:
Hey, so I have a CECHA01 PS3, it has YLOD. I've used the go to tutorials for this stuff, including the videos, especially by NSC modz, and I had issues with it because I don't know which model they have, and I've watched tons of other tutorials and they don't really say the model or anything, so I'm stuck not knowing where to connect the wires on my machine. Circled blue is TX and DX and black is ground. Also put a jumper between ground and the system board ground (copper edge of board). Set ft232r at 3.3v. Set to com3. During auth process it says "program error" , "unicode error", and never gives auth. Any help would be appreciated greatly.

X5dLGGR
Click to expand...
NSC's video description has a link to a file with instructions, including photos of where to connect on several different motherboards, as well as the script you need to run.
 
vyktormvmpay25 said:
Imo for user TYRANT rsx reflow /reball rsx problem. If reset image or pass to safe mode /recovery won't be possible still normal glod. Is still rsx imo.
Click to expand...

That's what I feared, all the clues point there.

I am undecided whether to try to reball or not (high price and unsecured result).
For now i put it aside, and play with the other one that is still working.

I want to thank all the users who have provided me with support (and endured :smile new:).
 
k1netic said:
Removing R6374/R6375 (unsure which is which on the board but I guess it doesn't matter) has eliminated the short across the MOSFETs and capacitors in parallel in that area. So with 1 resistor still in place the short is gone. I removed both and both tested 33ohms, so unsure if they could be faulty while reading the correct resistance?

Putting just one resistor back on the board, replacing fuse 6302, and replacing capacitor c6320 and the console boots up to xmb.

I won't be stress testing yet as I'm now waiting for resistors to be delivered, I assume running the console with one missing is a problem down the road waiting to happen.

I do have a working donor cech-k02 here, I took fuse 6001 from it and the capacitor from the same location as c6320 to repair the cech-c02, but couldn't find a service manual for it to point me in the right direction for a resistor of 33ohms and correct case size. Any hints for that? Then I can put the c02 back together and replace the parts on the k02 later...
Click to expand...

I've fired up the cech-c02 without replacing the 2nd resistor, sick of waiting for the part, and run the last of us for a while on evilnat 4.88.2 and a fan profile to keep it at or under 65 celcius. It runs fine. Fan speed gets to 33-34%. I haven't delid either the GPU or CPU as I have only tried once on another console so won't risk it before more practice.
 
Years ago I bought a bc PS3 with a chip on the corner of the cell to use for parts. I just checked the Syscon on a whim and it gave me 3034. I decided to reflow because I had never done it before and it cleared the 3034.

Now it gives 3031. The dev wiki just says cell. I thought it might be useful information since I know there's physical damage on the die, but I guess the error depends on the location of the damage. Does anyone know anything specific about 3031?
 
so, i just fired up the bgtoolset and if i understood correctly on the system manager the errors are syscon errors? but the weird thing is they all are a bunch of 0xA0802022, 0xA0805FFF and a single 0xA0802131 but they all range from 2008 to 2007 and a single from 1970 thats just F's but the dates are impossible since well slims werent even a thing back then, console has never ylod'ed
 
amxcs said:
Hello, can you help me with error A06114FF. I can't find any information.
Click to expand...
Step #61 is in the firmware sequence. I would suspect NAND/NOR corruption, but AFAIK that doesn't cause YLOD (HW failure). It would normally cause a GLOD. Perhaps the NAND/NOR or SS2 are dead. Or perhaps the Southbridge and it's interface with the HDD.

Step Numbers 61 & 62...
Load Firmware and OS
  • Errors reported with Step# 61 = 1101, 1802, and now your 14FF (Checkstop)
  • Bootloader runs and Southbridge accesses the FW stored on NAND/NOR. Not sure how the rest of this goes. But if it all goes well the operating system loads.
IBM said:
A checkstop occurs when - usually a processor but sometimes a cache, memory, or I/O bus controller - determines that something is in an "impossible" state. An error occurs that cannot be isolated to a particular bus transfer in progress, or a processor detects no progress being made...Checkstops are inherently hardware phenomena. They do not necessarily indicate a solid failure of a component, so diagnostics will rarely determine that a problem exists.
Click to expand...
 
Cosmic-R said:
so, i just fired up the bgtoolset and if i understood correctly on the system manager the errors are syscon errors? but the weird thing is they all are a bunch of 0xA0802022, 0xA0805FFF and a single 0xA0802131 but they all range from 2008 to 2007 and a single from 1970 thats just F's but the dates are impossible since well slims werent even a thing back then, console has never ylod'ed
Click to expand...
The results should be identical to the syscon errors dump tool, the data extraction code being fundamentally the same, however I adapted the date/time conversions to js, in theory that shouldn't make a difference but the feature is new and could always contain bugs I haven't detected, at the end of the day I could only test the code myself on a couple of slims.

I worked on this stuff quite a while ago and the code isn't exactly fresh in my memory but this is basically how it goes.
The syscon error date data isn't a date per se but a value representing the number of seconds elapsed since a reference date.
The typical reference date used by C, js etc.. is 1970, but for the syscon errors date data s#ny used 2006.
When the extracted syscon value is > 0, an algorithm uses it to make a conversion to a date using a function relying on 1970 as reference therefore having to correct the value taking into account the reference that s#ny used ie 2006.
But when the extracted syscon error value is 0 (simply because the error log slot has never been used), the calculated date comes up as 1970, maybe for coherence, I should set it to 2006, at the time I felt it made little difference really, FFFFFFFFs are "empty" slots anyway, the date should not really matter and I thought keeping 1970 could be a good way to indicate that the slot was initialized but unused.

If you have 30/40mn to spare, you could install HFW then HEN and run the syscon error dumper self to compare the results, before uninstalling HEN files and restoring OFW, if you find discrepancies, post them here and mention me.
 
Last edited:
bguerville said:
The results should be identical to the syscon errors dump tool, the data extraction code being fundamentally the same, however I adapted the date/time conversions to js, in theory that shouldn't make a difference but the feature is new and could always contain bugs I haven't detected, at the end of the day I could only test the code myself on a couple of slims.

I worked on this stuff quite a while ago and the code isn't exactly fresh in my memory but this is basically how it goes.
The syscon error date data isn't a date per se but a value representing the number of seconds elapsed since a reference date.
The typical reference date used by C, js etc.. is 1970, but for the syscon errors date data s#ny used 2006.
When the extracted syscon value is > 0, an algorithm uses it to make a conversion to a date using a function relying on 1970 as reference therefore having to correct the value taking into account the reference that s#ny used ie 2006.
But when the extracted syscon error value is 0 (simply because the error log slot has never been used), the calculated date comes up as 1970, maybe for coherence, I should set it to 2006, at the time I felt it made little difference really, FFFFFFFFs are "empty" slots anyway, the date should not really matter and I thought keeping 1970 could be a good way to indicate that the slot was initialized but unused.

If you have 30/40mn to spare, you could install HFW then HEN and run the syscon error dumper self to compare the results, before uninstalling HEN files and restoring OFW, if you find discrepancies, post them here and mention me.
Click to expand...
i already have hen but since ive no idea how to run a self file nor i found a error dumper thats just the self i used the PS3 Advanced Toolset and this was the output, they all are the same except the last one instead of defaulting to 1970 its 1999.

also what is 5FFF, i know 2131 says its rsx temp but ive never had any temp warning whatsoever, 2022 seems to be te av multi out ic but again never had issues with it used for years unitl i had my hdmi port fixed that was physically broken. hardly ever had random shutdowns and they all have been in hen mode iirc while booting games ? so its that what you would call a panic mode ?.

ive no problems with my console just got curious and thought it was weird the dates being from before the console even existed and error codes that as far as i am aware of never had any issues with


Code: 
Firmware Version: 4.86 (build 50715)
Platform ID: CokK10
Product Code: 00 84
Product Sub Code: 00 0C
Hardware Config: (dont know if this is unique info)
Syscon Fimware Version: 0918.0000000000000000 (EEPROM: 0000000000000000)

Bringup Count: 5134, Shutdown Count: 5038
Runtime: 850 Days, 20 Hours, 49 Minutes, 24 Seconds

Error Log
01: A0802131  Tue Aug  5 23:10:47 2008
02: A0805FFF  Fri Jul 25 02:05:57 2008
03: A0805FFF  Sat Jul 12 21:01:32 2008
04: A0802022  Fri Jun 27 01:15:54 2008
05: A0802022  Fri Jun 27 01:14:10 2008
06: A0805FFF  Sat Dec  8 21:35:06 2007
07: A0802022  Sun Jul 15 19:06:27 2007
08: A0802022  Sun Jul 15 18:57:33 2007
09: A0802022  Sun Jul 15 18:57:26 2007
10: A0802022  Sun Jul 15 18:54:50 2007
11: A0802022  Sun Jul 15 04:57:05 2007
12: A0802022  Sun Jul 15 04:55:02 2007
13: A0802022  Sun Jul 15 04:54:55 2007
14: A0802022  Sun Jul 15 04:53:22 2007
15: A0802022  Sun Jul 15 04:53:16 2007
16: A0802022  Sun Jul 15 04:40:06 2007
17: A0805FFF  Tue Jul  3 22:25:26 2007
18: A0805FFF  Wed Jun 20 02:35:19 2007
19: A0802022  Fri Jun 15 00:53:02 2007
20: A0802022  Fri Jun 15 00:44:32 2007
21: A0802022  Wed Jun 13 21:12:39 2007
22: A0802022  Wed Jun 13 20:56:35 2007
23: A0802022  Wed Jun 13 20:53:52 2007
24: A0802022  Wed Jun 13 20:53:11 2007
25: A0802022  Fri Jun  8 02:05:54 2007
26: A0802022  Fri Jun  8 01:45:51 2007
27: A0805FFF  Sat Jun  2 01:33:53 2007
28: A0805FFF  Sat Jun  2 00:24:26 2007
29: A0802022  Thu May 31 03:42:06 2007
30: A0802022  Thu May 31 03:09:50 2007
31: A0802022  Mon May 28 02:44:21 2007
32: FFFFFFFF  Fri Dec 31 23:59:59 1999
 
Last edited:
RIP-Felix said:
Step #61 is in the firmware sequence. I would suspect NAND/NOR corruption, but AFAIK that doesn't cause YLOD (HW failure). It would normally cause a GLOD. Perhaps the NAND/NOR or SS2 are dead. Or perhaps the Southbridge and it's interface with the HDD.

Step Numbers 61 & 62...
Load Firmware and OS
  • Errors reported with Step# 61 = 1101, 1802, and now your 14FF (Checkstop)
  • Bootloader runs and Southbridge accesses the FW stored on NAND/NOR. Not sure how the rest of this goes. But if it all goes well the operating system loads.
Click to expand...
With a pressure test - it starts - GLOD. It should be a BGA defect?


I also have another slim console that cannot be updated. It gets to 20-22% and gives error 8002f147. I tried several firmwares from 4.81 to 4.89 and 3-4 different hard drives. Tried syscon diagnostics - no errors.
I read in some places that the problem could be with the bt/wifi module. Is there a way to test it?
Is there a way to find out if the problem is software or hardware. I watched a video on YouTube that this error can be fixed with a flash.

Code: 
>$ powerstate
00000000
# ATA :OFF
# PCI :OFF
# PCIex:OFF
# RSX :OFF
# GDDR :OFF
# XDR :OFF
# EURUS:OFF
# SB :OFF
# LAN :OFF
# WLAN : ON
 
amxcs said:
With a pressure test - it starts - GLOD. It should be a BGA defect?


I also have another slim console that cannot be updated. It gets to 20-22% and gives error 8002f147. I tried several firmwares from 4.81 to 4.89 and 3-4 different hard drives. Tried syscon diagnostics - no errors.
I read in some places that the problem could be with the bt/wifi module. Is there a way to test it?
Is there a way to find out if the problem is software or hardware. I watched a video on YouTube that this error can be fixed with a flash.

Code: 
>$ powerstate
00000000
# ATA :OFF
# PCI :OFF
# PCIex:OFF
# RSX :OFF
# GDDR :OFF
# XDR :OFF
# EURUS:OFF
# SB :OFF
# LAN :OFF
# WLAN : ON
Click to expand...
Hardware 2f147, what slim?
Do that powerstate on this slim see "WLan :ON"?
 
Check 1v8 line for WiFi in standby, also 3v3 should be present, Idk would syscon say on but you get WiFi error. Check power line around WiFi and lan ic. If you find any cap in short just remove that ic and test for short again.
 
sandungas said:
But it seems is not enought... something more is needed :(
Click to expand...
Yes, the PS3 needs to run a JIG firmware, be connected to the factory server and syscon needs to be remarried. You can bypass the factory server part but not the JIG firmware/Syscon Remarry. The normal firmware doesn't have the rtc set functions and syscon will only accept them during the remarrying process.
Cytology syscon firmwares do have a "rtc set" uart command though.
 
You must log in or register to reply here.

Similar threads

Back
Top