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

[RIP-Felix]

@sandungas ... a 2nd PS3 motherboard model DIA-001 and this one is giving errors about the RSX chip:

===================================
ERR 00: 00000000 A0403034 FFFFFFFF
ERR 01: 00000000 A0404002 FFFFFFFF
ERR 02: 00000000 A0232102 FFFFFFFF
...

Yeah, that one needs reballed. A reflow with that equipment is more likely to harm the motherboard than to fix the console. And even if it does, it won't last long. That's the nature of reflows. Looks, like that one is a bust.

 

[Fallen777]

1200 is a CPU overheating error. I forget, did you replace the thermal paste between the CPU IHS/HS? I usually recommend deliding, but (if I remember correctly) didn't SONY stare soldering the IHS to the DIE for the SS?

The thing is, I really only work on backwards compatible consoles. I worked on one slim 3000 model, but really...I bought it only for parts and have not attempted fix it or figure out what changes the've made to it's design. For the most part they are following a similar design, so if you are familiar with the BC models (which we have schematics for), then you can guess what something does and where to find it. But the process is harder, because you have to lookup specific part numbers and datasheets, since they aren't always the same pinout (for example).

Long stort short, If replacing TIC doesn't work I'd replace the ADT7461 temperature monitor (or it's equivalent on your SS board). You could check to be sure it's getting 3.3v VCC input. But it is probably only enabled after startup, so you'll have to start the console, watch the voltage, and record it before the YLOD. This is the procedure for most voltages. Start, measure, reset...move to next voltage and repeat.

1200 is a CPU overheating error. I forget, did you replace the thermal paste between the CPU IHS/HS? I usually recommend deliding, but (if I remember correctly) didn't SONY stare soldering the IHS to the DIE for the SS?

Yeh we been through that before ihs is solder on superslims its actually changed to solder from cech 3000x to 4300x.Just don't know where's vms on cell and rsx on pqx and other motherboards maybe someone else can point them out if you know someone familliar with these boards do tag em along will you

 

[RIP-Felix]

Yeh we been through that before ihs is solder on superslims its actually changed to solder from cech 3000x to 4300x.Just don't know where's vms on cell and rsx on pqx and other motherboards maybe someone else can point them out if you know someone familliar with these boards do tag em along will you

Ah, okay. I couldn't remember or find the post.

Anyway, here's your temp monitor.

I assume it's an ADT7461, like what's on the BC models. I can tell it's the temp monitor because of the arrangment of RC circuit on the data pins for the remotes sense line. That capacitor between them is for noisy environments. So if there is a lot of noise, it could interfere with the remote sense of the temp monitor and cause a 1200.

It's unlikly, but possible there's a BGA defect on the temp monitor line that connects to the CPU's internal thermocouple. It'd be very unlikly that's the only broken BGA tho. Also, there's a remote chance the thermocouple itself has gone bad because the CPU burned out. That the CPU is dead.

This is something I've been researching, but have not made much progress on. Here's the part and datasheet if you want to read up on it. You can order a new one, but double check it's compatible with the part SONY actually put on your motherboard. The picture above (from dev wiki) is too grainy to see what it is.

 

[RIP-Felix]

SC EEPROM Offset	Block ID	Block Offset	Description	Physical Offset
0x48000 - 0x480FF	0x00	0x48000 - 0x480FF	?	0x7000
0x48800 - 0x488FF	0x01	0x48800 - 0x488FF	Hypervisor Area	0x7100
0x48C00 - 0x48CFF	0x02	0x48C00 - 0x48CFF	Contains flags and tokens/ see above	0x7200
0x48D00 - 0x48DFF	0x03	0x48D00 - 0x48DFF	System Data Region	0x7300
0x2F00 - 0x2FFF	0x10	0x2F00 - 0x2FFF	"Industry Area" aka OS Version Area	0x2F00
0x3000 - 0x30FF	0x20	0x3000 - 0x30FF	"Customer Service Area"	0x3000
N/A	0xFF	N/A	? sys_boot_gos flag is there	No SC EEPROM activity
All other offsets	Invalid	Invalid	?

...

I have been looking at the step number and collating all the SYSCON errors people have reported by the step number they occured at. I'm trying to build a picture of what kind of errors we can see at which step number. That should help build a picture of what's wrong.

But I couldn't help notice that the Block ID seems to correlate to the step number. Is that the case?

@M4j0r pointed this out to me recently...

00-11 Power Sequence Init, Basic Voltage/Clock Init...
20-22 CELL Init
23    Check for RSX/SB/CP...
30-32 More CELL Init
40    Bit Training
50    RSX Init
51-52 SB Init
60-62 More CELL Init
FF    Finish

lv0ldr loading probably starts with step 60 and it gets executed after step FF (=80).
You can see that here: https://pastebin.com/BaCFugAU .

!!! WARNING !!!

!!! SYSCON RESET DETECTED !!!

Syscon Service Manager started.

Bringup Mode #0 (0xFF)

[WMM0] Watch module manager started.

[WMM1] Watch module manager started.

BD is available.

BE-SC Communication Module started.

[SSM] state: 0000 -> 0101
Bringup Mode #0 (0xFF)
[SSM] ssmCb_OnStartingBePowOn() called.
[SSM]Fake Eject.
[SSM] First Boot.
[SSM] Bringup mode : syspm_stat=00000000/00000000
[POWSEQ] PowerSeq_Setup called.
**************************
*** PowerSeq Step = 00 ***
**************************
**************************
*** PowerSeq Step = 01 ***
**************************
**************************
*** PowerSeq Step = 02 ***
**************************
**************************
*** PowerSeq Step = 03 ***
**************************
**************************
*** PowerSeq Step = 04 ***
**************************
**************************
*** PowerSeq Step = 05 ***
**************************
**************************
*** PowerSeq Step = 06 ***
**************************
**************************
*** PowerSeq Step = 07 ***
**************************
**************************
*** PowerSeq Step = 08 ***
**************************
**************************
*** PowerSeq Step = 09 ***
**************************
**************************
*** PowerSeq Step = 10 ***
**************************
**************************
*** PowerSeq Step = 20 ***
**************************
[SSM] state: 0101 -> 0201
[POWSEQ] AV Backend Setup
[SSM] state: 0201 -> 0102
**************************
*** PowerSeq Step = 21 ***
**************************
**************************
*** PowerSeq Step = 22 ***
**************************
[SSM] state: 0102 -> 0202
[SSM] state: 0202 -> 0103
**************************
*** PowerSeq Step = 23 ***
**************************
**************************
*** PowerSeq Step = 30 ***
**************************
[SSM] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
BE_LIVELOCK_MODE:0xff
BE_LIVELOCK_ACTION:0x2
BE_LIVELOCK_QUIESCE:0xff
[SSM] state: 0203 -> 0104
**************************
*** PowerSeq Step = 31 ***
**************************
**************************
*** PowerSeq Step = 32 ***
**************************
**************************
*** PowerSeq Step = 40 ***
**************************
Psbd_SbTransMode_Full:0x20e2
**************************
*** PowerSeq Step = 50 ***
**************************
**************************
*** PowerSeq Step = 51 ***
**************************
**************************
*** PowerSeq Step = 52 ***
**************************
**************************
*** PowerSeq Step = 60 ***
**************************
[SSM] state: 0104 -> 0204
[SSM] state: 0204 -> 0105
**************************
*** PowerSeq Step = 61 ***
**************************
**************************
*** PowerSeq Step = 62 ***
**************************
**************************
*** PowerSeq Step = FF ***
**************************
[SSM] state: 0105 -> 0400
(PowerOn State)
[SERV NVS] READ CMD
[INFO]: trace level 3
[INFO]: timebase_clock 04c4b400(4f)
check_board_version: Cyt2 is false. Cyt3.2
check_board_version: Cyt3 is true. Cyt3.2
livelock_detection is enable.
be::setup_default(true)
sb::setup_default(true)
rs::setup_default(true)
exist RS

Boot Loader SE Version 0.8.5 (Build ID: 1257,12300, Build Data: 2006-07-06_02:22:23)
Copyright(C) 2006 Sony Computer Entertainment Inc.All Rights Reserved.
[INFO]: xdr::query_config (basic) returns 0x00000000
[INFO]: query_system_power_up_cause returns successfully.
[INFO]: requested_os_context: 0x00
[INFO]: current_os_context  : 0x00
[INFO]: requested_gr_context: 0x00
[INFO]: current_gr_context  : 0x00
[INFO]: last_shutdown_cause : 0x00
[INFO]: wake_source         : 0x00000004
[INFO]: b_str: bool(0)
[INFO]: xio_ref_clk: 400 MHz
[INFO]: be_ref_clk: 400 MHz
[INFO]: be_pll_multiplier: 8
[INFO]: dump basic_config byte stream: size 128
04:02:10:20:08:00:00:01:80:00:ff:c0:32:00:06:11:
01:70:7c:fe:48:20:00:00:01:e0:62:84:05:5a:d6:b0:

5d:70:71:80:02:10:00:00:0a:96:3d:60:e1:c0:c8:00:
00:00:00:00:00:00:00:00:ed:d6:12:29:59:4b:a6:b4:
53:49:ac:b6:88:c4:62:20:00:00:00:00:00:40:00:00:
08:a0:0c:a0:14:79:18:79:00:58:00:80:00:01:fc:01:
00:06:00:0f:fc:0a:00:06:00:0f:37:00:00:3f:23:28:
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
[INFO]: ------------------------------- dump end
[SERV SETCFG] XDR (CH0,CH1) ASSERT
[SERV SETCFG] XDR (CH0,CH1) DEASSERT
[WMM1] timeout.(1344)

[INFO]: XDR Link successfully initilized.
check_board_version: Cyt2 is false. Cyt3.2
check_board_version: Cyt3 is true. Cyt3.2
check_board_version: Cyt1 is false. Cyt3.2
check_board_version: Cyt2 is false. Cyt3.2
check_board_version: Cyt3 is true. Cyt3.2
[INFO]: flash format 1
[INFO] is_boot_memory_type_nand type 257
[INFO]: DX configuration start.
copy_to_main_memory: src 2401fc40200, size 000003e0
copy_to_main_memory: start_sector 00000201, sector_count 00000002
copy_to_main_memory: copied_addr 01010080, offset 00000480
copy_to_main_memory: src 2401fcc0000, size 00000020
copy_to_main_memory: start_sector 00000600, sector_count 00000001
copy_to_main_memory: copied_addr 01010480, offset 00000680
copy_to_main_memory: src 240203c0010, size 000003e0
copy_to_main_memory: start_sector 00003e00, sector_count 00000002
copy_to_main_memory: copied_addr 01010690, offset 00000a80
copy_to_main_memory: src 24020476ea0, size 0004b550
copy_to_main_memory: start_sector 000043b7, sector_count 0000025b
copy_to_main_memory: copied_addr 01010b20, offset 0004c080
[INFO]: Connecting to Debug Device (CP)
[SERV NVS] READ CMD
[INFO]: trace level 3
[INFO]: timebase_clock 04c4b400(4f)
memory_budget::initialize: addr = 0x56000, size = 0x6c000
memory_budget::initialize: addr = 0x1c000000, size = 0x4000000
allocate (0x400, 0x1000)
allocate (0x3000, 0x1000)
allocate (0x110000, 0x10000)
ea_addr_ss2 0x000000001c010000, m_io_addr_ss2 0x0000000000000000, size_ss2 00100080, allocate_size 00110000
allocate (0x8000, 0x80)
allocate (0x8000, 0x80)
devpm_version 0101
[SERV DEVPM] GET_PCI_BUS_POWER_STATE CMD
get_power_status<pci_bus> status 0
set_power_status<pci_bus> on
[SERV DEVPM] CONTROL_PCI_BUS_POWER_STATE CMD
[WMM1] timeout.(432)
[SERV DEVPM] GET_PCI_BUS_POWER_STATE CMD
set_power_status<pci_bus> success
allocate (0x100000, 0x1000)
get pif5 parameter. cp_version(00000000_00000808), param(02010000_00000000)
[INFO]: force standalone mode
allocate (0x12000, 0x1000)
allocate (0x12000, 0x1000)
allocate (0x12000, 0x1000)
output: debugI/F was selected
[SERV NVS] WRITE CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD

---- Cytology-Genri2 BOARD CONFIGURATION ----
BE VRM:FF
RS VRM:FF
BE VRM 2ND:FF
XCG BE:FF RS:FF RRAC:20 XDR:FF
USE_XCG2:TRUE (00)
XCG2 BE 5:84 6:16
XCG2 RS 5:FF 6:FF
XCG2 XDR 5:84 6:16
SB_TRANS_MODE:FULL (01)
USE_RS:TRUE (00)
USE_SB_CHECKSTOP:TRUE (00)
SB IOIF RESET:TRUE (FF)
BE_CHIP_VER:DD3.1
SB_CHIP_VER:#3.2
RS_CHIP_VER:RSX B01
SECU_OVER:NONE
BE_PLL_ENABLE:DISABLE
BE_PLL:FF FF FF FF FF FF FF FF
MASTER SPU:00
-----------------------------------

Now that log shows step numbers
0-10
20
...and ends with FF like the Block ID. That looks like a pattern to me. Does someone have that whole chart? It has a description of each offset in the SC eeprom for 00-03, but doesn't show all of them. If these block ID's do correspond to the Step number checks in the powerup sequence, then we have a roadmap of what exactly the syscon is doing at each step number. That give powerful insight into what errors occurring at each step could mean.

 

[sandungas]

Ah, okay. I couldn't remember or find the post.

Anyway, here's your temp monitor.
View attachment 35330

I assume it's an ADT7461, like what's on the BC models. I can tell it's the temp monitor because of the arrangment of RC circuit on the data pins for the remotes sense line. That capacitor between them is for noisy environments. So if there is a lot of noise, it could interfere with the remote sense of the temp monitor and cause a 1200.

It's unlikly, but possible there's a BGA defect on the temp monitor line that connects to the CPU's internal thermocouple. It'd be very unlikly that's the only broken BGA tho. Also, there's a remote chance the thermocouple itself has gone bad because the CPU burned out. That the CPU is dead.

This is something I've been researching, but have not made much progress on. Here's the part and datasheet if you want to read up on it. You can order a new one, but double check it's compatible with the part SONY actually put on your motherboard. The picture above (from dev wiki) is too grainy to see what it is.

The thermal monitors of the first PS3 models was made by "Onsemi" (or Analog devices), but around PS3 slim was replaced by others made by texas instrument
As far i understand are logical and phisically compatible with the previous versions, there is a (incomplete) list in wiki made with the help of vyktor, he was checking a lot of motherboard models and we was trying to identify them (is tricky because the way how they are labeled sucks)
https://www.psdevwiki.com/ps3/Thermal#Temperature_Monitors

Btw, you could take a thermal monitor for RSX and solder it in CELL, or the other way around. But dont do this, is not going to work because they have a (software) ID hardcoded from factory, and we dont know how to change it
In other words... a thermal monitor for CELL have a product number and a ID specific for CELL
Syscon is going to recognize it by his ID... so if we solder 2 thermal monitors for CELL together (in the same data line) syscon is not going to be able to "read" them (most probably is not going to recognize them)

-----
When you said "capacitor between them" you mean in between pins D+ and D-, right ? (the lines that goes to the diode inside CELL or RSX)
Yeah, i dont know the exact purpose or the theory behind it, but it seems to be some kind of filter, i would say this is the first thing we should check (because is the most optimistical approach, easy to check and fix)

-----
Btw, in the "syscon error codes" page in wiki you added many notes mentioning the component code, like IC1004 or things like that...
Is fine as an initial approach but i have to said thats not good enought, because a lot of them only applyes to a specific motherboard model
The solution i see is to add some notes everytime is mentioned a component code as example: Thermal monitor (IC1004 on COK-001 motherboard, or IC1005 in COK-002 motherboard)

*At some point i need to review that page to add also a lot of links to other wiki pages, you know... everytime is mentioned CELL is better to create a link with it this way: [[CELL BE|CELL]]
Or... [[RSX]]
Or... [[Thermal#Temperature_Monitors|Thermal Monitor]]
Is handy for wiki readers to navigate other pages searching for more info (usually in the other pages appears the pinouts, etc...)

 

[RIP-Felix]

...I think for now I am going to put this unit on the back burner until I either get a NOR reader or potentially just take a flash chip off another board with a fault that I can not fix (if that is even possible).

This isn't too bad. I'd probably go this path myself.
[MEDIA=youtube]s4Cs-4ceM88[/MEDIA]

He doesn't actually show the flashing/rebuilding process (shame), but I'm sure others here can explain. I haven't had to do this myself yet, thank god. But it seems doable. On the other hand, you could ask Voultar if he's willing to do it for you, since he has the programmer. I can certainly vouch for the guy!

 

[sandungas]

But I couldn't help notice that the Block ID seems to correlate to the step number. Is that the case?

I was thinking about it too, but im not sure if is directly related

Does someone have that whole chart? It has a description of each offset in the SC eeprom for 00-03, but doesn't show all of them. If these block ID's do correspond to the Step number checks in the powerup sequence, then we have a roadmap of what exactly the syscon is doing at each step number. That give powerful insight into what errors occurring at each step could mean.

The other day i was trying to see how to join all the info from the "SC EEPROM" wiki page into a single table, is a technical talk that took some days and started here and is still a "work in progress" because i dont know yet how is the best way to do it

 

[RIP-Felix]

Btw, in the "syscon error codes" page in wiki you added many notes mentioning the component code, like IC1004 or things like that...
Is fine as an initial approach but i have to said thats not good enought, because a lot of them only applyes to a specific motherboard model
The solution i see is to add some notes everytime is mentioned a component code as example: Thermal monitor (IC1004 on COK-001 motherboard, or IC1005 in COK-002 motherboard)

*At some point i need to review that page to add also a lot of links to other wiki pages, you know... everytime is mentioned CELL is better to create a link with it this way: [[CELL BE|CELL]]
Or... [[RSX]]
Or... [[Thermal#Temperature_Monitors|Thermal Monitor]]
Is handy for wiki readers to navigate other pages searching for more info (usually in the other pages appears the pinouts, etc...)

I think we should add a disclaimer at the top that references to, say IC6001 (for example), is for COK-001 boards. That the design revisions are similar, although part numbers may change. But since we only have 3 schematics to go off of, we chose to list COK-001 numbers for simplicity. Besides, that's what the errorlog key is referring to.

 

[sandungas]

I think we should add a disclaimer at the top that references to, say IC6001 (for example), is for COK-001 boards. That the design revisions are similar, although part numbers may change. But since we only have 3 schematics to go off of, we chose to list COK-001 numbers for simplicity. Besides, that's what the errorlog key is referring to.

Is not so costly (in text lenghts), and is very accurate, we only have 3 service manuals so the worst case posible is when we need to add 3 names
As far i remember the thermal monitor differs, but i guess in most cases are going to match in the 3 service manuals, so is just a matter of writing something like... (IC1005 on COK-001, COK-002, and DIA-001)
You know something short, but very explicit... it means we are 100% sure the names are correct for that motherboard models... and the others not mentioned is because we dont know

 

[Pavel]

Before replacing tokins, try replacing IC2408. I strongly suspect that converter.

Vout being short to ground may be internal. Once you work it off the board the short should be gone. If so, replace it. If not, keep removing resistors and caps down stream.

Hi, there!
Sorry for being silent for a while - I've been a bit sick and meanwhile sourced another PS3 CECHC with GLOD issue. First thing I did was to check IC2408 readings and they appeared to be the same as on the new board.

However, to my surprise, it REALLY was the faulty power supply! So, the first board with 1004 error works fine after PSU replacement (at least it starts in the safe mode - haven't tested beyond that).

Now, I'm left with the GLOD board and APS-227 PSU to fix! :-D
Will run SYSCON diag and will update.
Thanks for your help!

 

[RIP-Felix]

Hi, there!
Sorry for being silent for a while - I've been a bit sick and meanwhile sourced another PS3 CECHC with GLOD issue. First thing I did was to check IC2408 readings and they appeared to be the same as on the new board.

However, to my surprise, it REALLY was the faulty power supply! So, the first board with 1004 error works fine after PSU replacement (at least it starts in the safe mode - haven't tested beyond that).

Now, I'm left with the GLOD board and APS-227 PSU to fix! :-D
Will run SYSCON diag and will update.
Thanks for your help!

GLOD can be more tricky than YLOD. PSU repair is dangerous, so I dont recommend it! Often the best way to fix a console is to buy a broken one for parts and start testing. Sounds like you got a lucky one, with basically the easiest solution! First step is to try PSU. Almost never works, but hay...Congratz!

We'll see if the C model is worth fixing, but you'll at least need a PSU. They aren't much cheaper than buying another console for parts. You can see how this leads down a rabbit hole. That's how I ended up with 10 PS3's in various states of working, not working, reballed to death, awaiting reballing or frankensteining, etc. It becomes a problem.

If your goal was to fix a PS3 and enjoy it, then mission acomplished. You may find it a better option to sell the other one for parts and be done. But yeah, lets see what the errors are. If its and easy fix, then it'd be worth more working.

 

[gumpdumb]

Hi, i got faulty ps3 CECHK06 DIA-002 brought my brother having YLOD problem. The tokin still in place, no flux residue seeing any other place, the sticker already peel off.
Need some guide and help what the step taking down this problem. Thanks

errlog
ofst[ 68]:err_code:0xffffffff, clock:0xffffffff
ofst[ 72]:err_code:0xa0801002, clock:0x0b4a228b 2006/01/01 05:18:03
ofst[ 76]:err_code:0xa0231002, clock:0x0b4bcbf6 2006/01/02 11:33:10
ofst[ 80]:err_code:0xa0233020, clock:0x0b4bcbf6 2006/01/02 11:33:10
ofst[ 84]:err_code:0xa0002120, clock:0x0b4bcbf7 2006/01/02 11:33:11
ofst[ 88]:err_code:0xa0801002, clock:0x0b4bcc13 2006/01/02 11:33:39
ofst[ 92]:err_code:0xa0221002, clock:0x0b4bcc18 2006/01/02 11:33:44
ofst[ 96]:err_code:0xa0002120, clock:0x0b4bcc19 2006/01/02 11:33:45
ofst[100]:err_code:0xa0101002, clock:0x0b4bcc56 2006/01/02 11:34:46
ofst[104]:err_code:0xa0202120, clock:0x0b4bcc57 2006/01/02 11:34:47
ofst[108]:err_code:0xa0202120, clock:0x0b4bcc57 2006/01/02 11:34:47
ofst[112]:err_code:0xa0202120, clock:0x0b4bcc58 2006/01/02 11:34:48
ofst[116]:err_code:0xa0202120, clock:0x0b4bcc59 2006/01/02 11:34:49
ofst[120]:err_code:0xa0202120, clock:0x0b4bcc5a 2006/01/02 11:34:50
ofst[124]:err_code:0xa0202120, clock:0x0b4bcc5b 2006/01/02 11:34:51
ofst[ 0]:err_code:0xa0202120, clock:0x0b4bcc5c 2006/01/02 11:34:52
ofst[ 4]:err_code:0xa0202120, clock:0x0b4bcc5d 2006/01/02 11:34:53
ofst[ 8]:err_code:0xa0202120, clock:0x0b4bcc5e 2006/01/02 11:34:54
ofst[ 12]:err_code:0xa0202120, clock:0x0b4bcc5f 2006/01/02 11:34:55
ofst[ 16]:err_code:0xa0231002, clock:0x0b4bcc72 2006/01/02 11:35:14
ofst[ 20]:err_code:0xa0233020, clock:0x0b4bcc72 2006/01/02 11:35:14
ofst[ 24]:err_code:0xa0002120, clock:0x0b4bcc73 2006/01/02 11:35:15
ofst[ 28]:err_code:0xa0231002, clock:0x0b4bcc7a 2006/01/02 11:35:22
ofst[ 32]:err_code:0xa0233020, clock:0x0b4bcc7a 2006/01/02 11:35:22
ofst[ 36]:err_code:0xa0002120, clock:0x0b4bcc7b 2006/01/02 11:35:23
ofst[ 40]:err_code:0xa0221002, clock:0x0b4bcc81 2006/01/02 11:35:29
ofst[ 44]:err_code:0xa0222120, clock:0x0b4bcc81 2006/01/02 11:35:29
ofst[ 48]:err_code:0xa0002120, clock:0x0b4bcc82 2006/01/02 11:35:30
ofst[ 52]:err_code:0xa0221002, clock:0x0b4bcca0 2006/01/02 11:36:00
ofst[ 56]:err_code:0xa0002120, clock:0x0b4bcca1 2006/01/02 11:36:01
ofst[ 60]:err_code:0xa0003001, clock:0x0b513466 2006/01/06 14:00:06
ofst[ 64]:err_code:0xa0003001, clock:0x0b6037e4 2006/01/17 23:19:00

 

[M4j0r]

I have been looking at the step number and collating all the SYSCON errors people have reported by the step number they occured at. I'm trying to build a picture of what kind of errors we can see at which step number. That should help build a picture of what's wrong.

But I couldn't help notice that the Block ID seems to correlate to the step number. Is that the case?

Now that log shows step numbers
0-10
20
...and ends with FF like the Block ID. That looks like a pattern to me. Does someone have that whole chart? It has a description of each offset in the SC eeprom for 00-03, but doesn't show all of them. If these block ID's do correspond to the Step number checks in the powerup sequence, then we have a roadmap of what exactly the syscon is doing at each step number. That give powerful insight into what errors occurring at each step could mean.

The eeprom block id isn't related to the power sequence step number at all. The NVS block ids were added later. I don't know why they added these, they probably were already aware that the physical addresses won't be the same in the future.
Sherwood adds even more complexity to that, since the EEPROM is emulated. It doesn't follow the NEC Type01 or Type03 standards, it's custom. It hasn't been reversed so you can't extract data from the raw flash images without introducing errors.

 

[RIP-Felix]

Hi, i got faulty ps3 CECHK06 DIA-002 brought my brother having YLOD problem. The tokin still in place, no flux residue seeing any other place, the sticker already peel off.
Need some guide and help what the step taking down this problem. Thanks

errlog
ofst[ 68]:err_code:0xffffffff, clock:0xffffffff
ofst[ 72]:err_code:0xa0801002, clock:0x0b4a228b 2006/01/01 05:18:03
ofst[ 76]:err_code:0xa0231002, clock:0x0b4bcbf6 2006/01/02 11:33:10
ofst[ 80]:err_code:0xa0233020, clock:0x0b4bcbf6 2006/01/02 11:33:10
ofst[ 84]:err_code:0xa0002120, clock:0x0b4bcbf7 2006/01/02 11:33:11
ofst[ 88]:err_code:0xa0801002, clock:0x0b4bcc13 2006/01/02 11:33:39
ofst[ 92]:err_code:0xa0221002, clock:0x0b4bcc18 2006/01/02 11:33:44
ofst[ 96]:err_code:0xa0002120, clock:0x0b4bcc19 2006/01/02 11:33:45
ofst[100]:err_code:0xa0101002, clock:0x0b4bcc56 2006/01/02 11:34:46
ofst[104]:err_code:0xa0202120, clock:0x0b4bcc57 2006/01/02 11:34:47
ofst[108]:err_code:0xa0202120, clock:0x0b4bcc57 2006/01/02 11:34:47
ofst[112]:err_code:0xa0202120, clock:0x0b4bcc58 2006/01/02 11:34:48
ofst[116]:err_code:0xa0202120, clock:0x0b4bcc59 2006/01/02 11:34:49
ofst[120]:err_code:0xa0202120, clock:0x0b4bcc5a 2006/01/02 11:34:50
ofst[124]:err_code:0xa0202120, clock:0x0b4bcc5b 2006/01/02 11:34:51
ofst[ 0]:err_code:0xa0202120, clock:0x0b4bcc5c 2006/01/02 11:34:52
ofst[ 4]:err_code:0xa0202120, clock:0x0b4bcc5d 2006/01/02 11:34:53
ofst[ 8]:err_code:0xa0202120, clock:0x0b4bcc5e 2006/01/02 11:34:54
ofst[ 12]:err_code:0xa0202120, clock:0x0b4bcc5f 2006/01/02 11:34:55
ofst[ 16]:err_code:0xa0231002, clock:0x0b4bcc72 2006/01/02 11:35:14
ofst[ 20]:err_code:0xa0233020, clock:0x0b4bcc72 2006/01/02 11:35:14
ofst[ 24]:err_code:0xa0002120, clock:0x0b4bcc73 2006/01/02 11:35:15
ofst[ 28]:err_code:0xa0231002, clock:0x0b4bcc7a 2006/01/02 11:35:22
ofst[ 32]:err_code:0xa0233020, clock:0x0b4bcc7a 2006/01/02 11:35:22
ofst[ 36]:err_code:0xa0002120, clock:0x0b4bcc7b 2006/01/02 11:35:23
ofst[ 40]:err_code:0xa0221002, clock:0x0b4bcc81 2006/01/02 11:35:29
ofst[ 44]:err_code:0xa0222120, clock:0x0b4bcc81 2006/01/02 11:35:29
ofst[ 48]:err_code:0xa0002120, clock:0x0b4bcc82 2006/01/02 11:35:30
ofst[ 52]:err_code:0xa0221002, clock:0x0b4bcca0 2006/01/02 11:36:00
ofst[ 56]:err_code:0xa0002120, clock:0x0b4bcca1 2006/01/02 11:36:01
ofst[ 60]:err_code:0xa0003001, clock:0x0b513466 2006/01/06 14:00:06
ofst[ 64]:err_code:0xa0003001, clock:0x0b6037e4 2006/01/17 23:19:00

Did you test the console without the 2 prong 12v line connected? There is a 3001 that can happen if you did. If not, I would try another PSU.

Looks like you captured the entire error history.

I'm seeing some 1002's in your log that could be bad tokins. Thing is, they are occuring super early in the step number, which makes me wonder if there's an issue with the PWM controller. They started off happening when the console was powerd on (80). Then went strait to 10, 23, 22...low step number. Lots of early 2120's and a lone 3020 in there too, which might be a clue.

So yeah, tokins are possable. The PWM Buck controller and Buck converters are possable. About any of the SMDs in that line. Probably easiest to start with the tokins tho.

 

[feng_ye]

A few days ago I got a slim PS3 from a local tip shop, model CECH 2102A(mainboard SUR001, 40nm RSX so should be pretty okay), claiming it's not accepting disk but after it arrived I found everything was working(yay). So began the clean up and re-paste process. During the disassembly, the thermal grease was holding up the heatsink pretty hard and I used a hair dryer to soften it a bit, but still a quite visible bent on the mainboard. This happens all the time and I did this hair dryer trick all the time so I didn't think it will be a problem. However, after I put everything back I found this slim cannot boot and shows flashing red light with 3 beeps. Strangely there was no amber or yellow light, even for a short period. Desperately to find UART solder points and got the error codes, it were 3034 and 4102(the latter one could be wrong but 3034 is firm). Dang! I thought the bent of mainboard just ruined the BGA soldering point! To verify that, I externalised the PSU and laid the mainboard flat on the ground. During booting, I pressured the RSX/Cell with my fingers pretty hard, and it booted! Just my finger got burnt and can't keep pressing it but now I can confirm it's 100% solder contact problem.

Just about to shelf this poor thing, one of my friends joked about this by saying I should put a big rock on top of it. As a second thought, I tried to use the thermal pad came with the PS3 on the other components(power regulators probably), they're about 1-2 mm thick. I tried to place them around the edge of the RSX facing towards Cell, then carefully assembled the RF shields and firmly screw the bolts holding the heatsink. Putting the minimal components back and tried my luck, but this time viola! I can't believe I can turn it back on with this trick??! I'm still putting it on idle mode to see how long it works. But I think this temporary fix trick seems pretty useful if anyone knows it's 3034 error and wants to save something from the disk/game/eeprom. I would be very surprised if there's no one mentioned/tried this before.

What I did was merely this, and later applied some thermal paste on Cell and RSX(probably not going to contact with heatsink but won't hurt I guess)

Spoiler: What I have tried

View attachment 35079

I will see how long does it to breakdown... again

UPDATE: it doesn't last very long. That slim PS3 has 600+ days on time now, and eventually decided to freeze up a few times today when kids watching youtube even at around 68C degrees. Run a game, frozen with artefacts, and then rebooted into XMB frozen after a few seconds with artefacts. So yes, only a temporary 'fix' lasts about 2 months.

 

[raidriar]

Can we access syscon log without soldering if we are able to get back into the XMB?

 

[RIP-Felix]

Can we access syscon log without soldering if we are able to get back into the XMB?

Yes, using ps3 advanced toolbox. Check the link in my signiture. Go to my syscon tutorial. Link is there.

 

[raidriar]

Yes, using ps3 advanced toolbox. Check the link in my signiture. Go to my syscon tutorial. Link is there.

Yes buconero already showed me, it works great. Bunch of 1001 errors on this particular unit even though it can still game. Usually happens after playing uncharted 2 for an hour

 

[feng_ye]

Did you test the console without the 2 prong 12v line connected? There is a 3001 that can happen if you did. If not, I would try another PSU.

Looks like you captured the entire error history.

I'm seeing some 1002's in your log that could be bad tokins. Thing is, they are occuring super early in the step number, which makes me wonder if there's an issue with the PWM controller. They started off happening when the console was powerd on (80). Then went strait to 10, 23, 22...low step number. Lots of early 2120's and a lone 3020 in there too, which might be a clue.

So yeah, tokins are possable. The PWM Buck controller and Buck converters are possable. About any of the SMDs in that line. Probably easiest to start with the tokins tho.

Second to that. I have at least two DIA-001/DIA-002 boards having the PWM buck controller issue, those mosfet and accompanying capacitor could be bad. Of course tokins could be the case too. Just don't replace tokins regardlessly. Probe those power mosfet for shorts, probe the controller IC(ISL6568) for voltage first(there's datasheet out there to reference). If those are all normal, then it could be tokins. Tokins caused issue happens really late, to my knowledge

 

[feng_ye]

Hi, just wanna share another fix story.

I bought a faulty BC model CECHC02 a few weeks ago. The machine actually can turn on a few seconds then goes to YLOD but at least you see XMB that's a good news. So I took it apart. It turns out the previous owner(s) have already heatgunned it, on CPU(but it has a fake sony warranty sticker on it, why people are dishonest these days), without cleaning thermal paste, so it was quite messy.

Tried my best to clean up and solder the syscon wires then re-assembled it. Then suddenly it won't turn on and became a very short YLOD. Error code shows 2110(Clock Generator Error IC5001). Some earlier code shows 1001 and 1002 so these are consistent with the truth it can turn on a while. Those 1001 and 1002 are probably due to bad tokins/power line capacitors issue.

Regardless, I researched the schematic and checked for shorts on the board. It turns out fuse F6001 was blown. And that fuse goes before the 12V enters Q6002, which eventually gives power to lots of 5V devices, including IC5001. So I thought I found the issue, then with my soldering iron I barely can replace a 5A fuse from a donor board then solder it back on. Before turning on I do check for shorts again, this time the whole power line, 12V -> GND, only has a resistance of about 100 Ohm. I knew I'm trying my luck, turn on, fuse blown again, same 2110 error.

So this made me wonder if it's actually Q6002 or other capacitors around it were short. But this check can only be done when I have a hot air rework station. Luckily the station I ordered arrived last week so I can work on that model again. The first capacitor I took off the board was C6019, and to my surprise it actually was the culprit of the short! Without this capacitor, all the power line readings are seemingly good. So I soldered another F6001 on. Turned on the machine, boom, it changed to 1001 error. Good news, at least fixed the short. Turn on a second time, 1200 error. Of course, I didn't have heatsink or fan on.

Spoiler: The Culprit

Assembled, turned on, not a single problem! I assume the 1001 error was "improved" when I put the board on the rework station's preheater and tokins' capacity were restored a bit.

However, the fan was really loud after idled in XMB a few minutes. Command tzone showed the CPU was idled at 78C degrees, with fan about 60% on. That's probably because the previous owner's heatgun speedup the drying process of the thermal paste inside of CPU's IHS. So I followed RIP-Felix's guide to make a delid tool, then practiced on two donor boards. Turns out quite well. Tried on this very board, was very close but still a success. So spread the thermal paste and put everything back. The fan was a lot quieter, with CPU at 67C and 29% fan.

I am quite happy with the result. This is the first BC model I've ever fixed, although I don't know how much damage the previous heatgun had done to the CPU.

EDIT: goodness it's the 2000th post in this thread, such a valuable thread I learnt so much from it. Thank you.