PS3 (Research/Experimental) - NEC/TOKIN Capacitors Replacement - YLOD

Hey people first of all, happy holidays to all of you :D

I made a video of a few YLODs I have over here, and compared them, seeing some aspects like time and light patterns. Maybe it could be useful for something. I'll put some notes of the consoles in the video.


*CECH-K Longest YLOD, it looks like this one needs a NEC fix. State: Warranty sticker intact.

*CECH-B Long YLOD, I added a few tantalums on RSX but green light time didn't change, I won't be touching this one for now. State: Bought in poor conditions, mobo remains untouched (thank god).

*CECH-A It has a "short but not instant" YLOD, if you wanna see it in that way, I think this could be BGA damage, or NECs, you never know without SYSCON.. State: Untouched.

*CECH-H_a This one died on me for the 2nd time, I suspect bgas are trolling me right now. I removed all the tantalums installed, leaving 4 NECs on CELL.

*CECH-H_b This one was also running and died for no reason, bgas maybe? No NECs at all. Notice the instant YLOD on these two Hs are the same.

*CECH-G Exact same green light time as "A", I think we have a pattern here. This "G" was bought running, died for no reason after test it a couple of times. This is a bga issue, from here to China. State: Untouched.

*CECH-E_a With all NECs removed in the back side, this one is doing something different, so this could be anything. I bought it with those NECs removed already..

*CECH-E_b A little slower than both Hs, but instant for sure. State: Untouched.

Those Hs were doing the same green time as the G when they had the tantalums installed.

One thing that I want you to notice, is that in the last segment of the video, if you pause it, you can clearly see how lights are shinning yellow/orange before the green light appears, indicating a problem even before the actual YLOD shows up. For example on E_a is easy to notice, and only B and H_b aren't doing this. Btw, all the consoles have the green light moment synced, since all of them have different behaviours before and after this state.

---------------------------------

@Yugonibblit

Hey man, how many fatties you fixed with the Super Slim caps? Are they reliable? Those consoles were tested good and are still alive? :D
Aha, that's a nice bunch of yellow lights (of death).
The way I see it, only the K there has the very interesting 5+ sec long YLOD. The rest sadly I don't think are telling us much. Actually the B there I still would say it's the normal YLOD (about 3 sec long. Sometimes closer to 2, sometimes closer to 4, like your B). The H models maybe especially short, but I have no experience with those models. The YLODs i saw in my C models were more or less the 3s ones. And I'm pretty sure it was not the capacitors. So that's what I'd call the YLOD (with the capital D)

Now it would be interesting to have a proper diagnosis for each of those consoles. SYCON ideally, but I think you could get lucky at least with the K model. The quick additional capacitor test may give you happy result.
As for the rest... I seriously doubt it.
(Remember if the quick test fails, capacitors are still not ruled out. But I think experience tells us it would be very low chance. More diagnosis is needed)

About that peculiarity you mention of the E model being yellow at the beginning... I would take that very lightly. Remember Yellow is just Red+ Green. The light is Red until the moment you press the button and green turns on (and red off). So yellow can be just a slight timing thing. Console had no time to think yet I believe.
Maybe you could try even swapping the buttons daughterboard, see if the behavior carries over. (Which may still be meaningless in and of itself. Mostly curiosity)

To me, what I may ask myself is very simple. Is the YLOD over 5 seconds long? If not, I'd still call it "short".
Then again, these are all conjectures. But since it costs nothing to notice, it's worth taking it into account.
 
I believe too that only K, and possible B, are clear candidates to resurrection, since Hs revived and died quickly. In my opinion A and G aren't THAT far, I remember I revived another G, and my BC A&C with not too long YLODs. But I could be wrong since that were months ago. The main problem I see with this is that "green light timing = caps state", I'm pretty sure that if you get a long YLOD, it means caps just died (and you have to turn on the console over and over like if it were an old car). But having a case like A/G doesn't mean caps aren't the issue too, or am I wrong? We'll see. I'm seeing those TTL adapters, but I'm not so sure which to pick, I never used one of this.

If you see that particular moment, almost all of them will go orange/yellow before the green led, it's wierd, first of all 'cause there are two that aren't doing that. Another mistery to the pile, I guess.

To me, what I may ask myself is very simple. Is the YLOD over 5 seconds long? If not, I'd still call it "short".
Then again, these are all conjectures. But since it costs nothing to notice, it's worth taking it into account.
IMO, B is already long, this because I compare it with the others, that's all. Something like K is definitely NECs, and (i.e) starting from B, you can have different behaviours/timing, depending of the caps situation. I'll update what's going on with these consoles once I learn how to do test in the first place lol.
 
@ElGris , This is the TTL Serial to USB converter I bought and it works great. What's important here is that the RX/TX lines are 3.3v, not 5v. The red wire is always 5v, but you wont connect that one for the SYSCON. Now I'm quite curious what SYSCON codes you get on all those consoles.

I'm still unclear on what codes we think implicate the NEC/TOKINs. Squeepts spreadsheet will help document the codes on consoles he works on, so that could help start making sense of them. @squeept the second A01 in your spreadsheet looks like it may warrant a tokin replacement on the Cell. Was the RSX really reading 2.8V DC? Should be 1.3ish. May be a lost cause! The Ohm test on it indicates the BGA "may" be in good shape. I noted that this resistance increased to around 3.5 Ohms after a reflow on mine. So if both the RSX and Filter caps are soldered in strong, that's the resistance I would expect to see. The Cell Vpp is excessive. The initial error code was implicating a thermal sensor error (IC2101), which is an ADT7461A dual channel thermometer used as the RSX temperature monitor. You indicate you did not make an attempt to repair? I would have a close look at the pins on IC2021, touching them up, and the resistors/caps in that circuit. It's possible the heat gun the previous owner used re-positioned the chip. If I remember correctly, the temp sensor failure was common back in the day after a failed reflow attempt. I'd also replace the tokins on the CPU. If you have any dead boards laying around, you could try replacing IC2101 if that doesn't clear up the 2031 error code. I suppose it's possible that a BGA defect on RSX_GPIO6 could cause a thermal sensor error too, but if there were BGA defects it'd probably be throwing more error codes than just a 2031.

EDIT:
@squeept You state "errlog old: A0213013, then a steady stream of A0202120. Shorts present near encoder chip and a bad choke. No attempt made." 3013 isn't an error code. 2120's are HDMI errors, which makes sense with your shorts and choke problem. May need to replace that chip. Microsoldering +BGA = not fun. I can see why you haven't made an attempt.
 
Last edited:
I can see why you haven't made an attempt.

My interpretation of the data was that the encoder chip was the first/real failure. Then the original owner/"repairer" got either no video or YLOD. So, then they assumed a BGA fault and heatgunned the F%$# out of the board and killed the RSX or CELL, giving the new errors that also seem to line up. Heatgun kind of people aren't the kind of people that nudge the chip to check their work, so I wouldn't expect any shorts underneath. That, combined with the excessive board warp from how crazy they went with the heatgun is why I called it early. I can bake out a decent amount of warp, but when I screwed down two corners in my clamp, a third one rose up like an inch. I didn't see any delamination, but I'd be hard pressed to believe they stayed in a safe temperature range to cause that kind of warp.


I assume violently murdering the chipset and surrounding components also borks the voltage, and they probably fried some TOKINs while they were at it.

I have the luxury of selling the drive, power supply, and fan quickly to recoup my costs and not tie up my equipment for low odds. So I quit a little bit earlier than some others might.

I think dbnumbers' first post has some of the errors he has encountered with his fixes and guesses. My first win lines up right. I still haven't seen another verified bad TOKIN, so we may be waiting awhile to get the first data point there.

I ain't scared of microsoldering. Here's the fixed pad (before I put some new mask on) from the first one in the spreadsheet. I didn't include the two n/c pads in the spreadsheet since they're n/c and always missing if there's any other damage.
XmUQnV7.jpg
 
Last edited:
@ElGris ,
I use a combination of 330 and 440 from slims,ps4, and junk old bc fats, I have fixed about 20 that I can remember but some were not repaired by just tantalums, I had to reflow a few after all tantalums were replaced, I'm running a cechh right now for at least 3 months that only needed 4 440 caps. It runs great also it has no blue ray drive. I'm using EVILNAT'S NO BD NO BT 4.87 CFW.
 
This is the TTL Serial to USB converter I bought and it works great. What's important here is that the RX/TX lines are 3.3v, not 5v. The red wire is always 5v, but you wont connect that one for the SYSCON. Now I'm quite curious what SYSCON codes you get on all those consoles.
It's funny, 'cause this was my first option in the list haha. It's a pl2303, and I read that the cp2102 has better drivers on Windows than the former? I think @marciolsf use this one. Well, I'm gonna buy both just in case (sometimes I screw up my things, yeap). If I need help with this I'm gonna be pm you :D

I suppose it's possible that a BGA defect on RSX_GPIO6 could cause a thermal sensor error too, but if there were BGA defects it'd probably be throwing more error codes than just a 2031.
How sure are you about this? Now that you mention it, I had an A with the cooler going in jet mode right after I turn it on, witt I believe it was an instant YLOD. I replaced NECs and even delid both processors, but that behaviour didn't change. Something like the E on my previous video, hear this: youtube.com/watch?v=8ZHuuqDCOBA

@ElGris ,
I use a combination of 330 and 440 from slims,ps4, and junk old bc fats, I have fixed about 20 that I can remember but some were not repaired by just tantalums, I had to reflow a few after all tantalums were replaced, I'm running a cechh right now for at least 3 months that only needed 4 440 caps. It runs great also it has no blue ray drive. I'm using EVILNAT'S NO BD NO BT 4.87 CFW.

20 are a lot of them O.O But it's good to know that or either you need to add tantalums/reflow, or both to make a console run. If you're lucky there won't be another bga issue for the rest of its life. It seems you are the lucky guy lol.

Btw, nice info!
 
It's funny, 'cause this was my first option in the list haha. It's a pl2303, and I read that the cp2102 has better drivers on Windows than the former? I think @marciolsf use this one. Well, I'm gonna buy both just in case (sometimes I screw up my things, yeap). If I need help with this I'm gonna be pm you :D


How sure are you about this? Now that you mention it, I had an A with the cooler going in jet mode right after I turn it on, witt I believe it was an instant YLOD. I replaced NECs and even delid both processors, but that behaviour didn't change. Something like the E on my previous video, hear this: youtube.com/watch?v=8ZHuuqDCOBA



20 are a lot of them O.O But it's good to know that or either you need to add tantalums/reflow, or both to make a console run. If you're lucky there won't be another bga issue for the rest of its life. It seems you are the lucky guy lol.

Btw, nice info!
Thanks, I guess I'm lucky, it seems that they all either need reflow or caps to me, but I'm no expert. Some are bricked and need to have hardware flasher like teensy or e3 flasher, teensy primarily just for nand consoles. But some are just dead.:sfun deadhorse::grenade:
 
Thanks, I guess I'm lucky, it seems that they all either need reflow or caps to me, but I'm no expert. Some are bricked and need to have hardware flasher like teensy or e3 flasher, teensy primarily just for nand consoles. But some are just dead.:sfun deadhorse::grenade:
When I get a consoles if they are YLOD first thing I do is give the motherboard an enema , which is get a dump, nand or nor and check it to see if it's good then I do the caps one at a time if it STILL YLOD then I do a reflow I guess you could do reflow first and get lucky! But if caps are failing then it won't last IMO. causing bag failure to be more prone from heat stress.
 
Last edited:
Don't you gonna try the SYSCON method too? Yeah, I was thinking the same, at least for discard any other issue apart of caps/bgas. I'm not using the reflow method 'cause my heatgun isn't that powerful, so adding a few tantalums in parallel with the NECs could be the solution in some cases, at least to make it boot up. By doing that you're sure that no heat is being apply to the board, and bgas are safe in the state they are.
 

Yeah, that's there. I can screenshot it for ya. The heatgun must have burned it so bad it made up a new error code. As for the A0A02031, that reads to me like the RSX is just completely and utterly burnt to a crisp, which is also what dbnumbers (yeah, that's their name now) guessed. The first thing the syscon does is try to read temperatures from the chip and it can't even get past that because the internal sensor was melted.

Don't use heatguns, fellas.
 
...How sure are you about this? Now that you mention it, I had an A with the cooler going in jet mode right after I turn it on, witt I believe it was an instant YLOD. I replaced NECs and even delid both processors, but that behaviour didn't change. Something like the E on my previous video, hear this: youtube.com/watch?v=8ZHuuqDCOBA

I was just looking at the COK-001 schematic and speculating. Because it's close to the RSX, the thermal sensor IC can be easily moved or damaged by a heatgun during a reflow attempt. If so it might throw that error. I suppose it's possible the fan might ramp up to 100% a split second before the YLOD. A BGA defect that only affects RSX_GPIO6 seems unlikely in comparison to something happening to the chip. However, like @squeept points out it's just a remote sense line. The thermocouple itself must be internal to the RSX, so if the RSX melts down, it could throw that error. If someone is using a heat gun to reflow the chip they can easily overdo the heat and melt the whole area down, killing the RSX and temperature monitoring IC, perhaps even the tokins. Processors tend to require more voltage as they age and get closer to death. That RSX was asking for 2.8V, indicating something catastropic occurred! Considering this and other evidence he noted, that story fits.
 
So I have replaced the first 2 nec tokens with 8 caps and managed to get rid of the yellow in the ylod. No it goes from red to green then red then a flashing red. Should I continue replacing caps?

Sent from my SM-G965U using Tapatalk
 
The main problem I see with this is that "green light timing = caps state", I'm pretty sure that if you get a long YLOD, it means caps just died (and you have to turn on the console over and over like if it were an old car). But having a case like A/G doesn't mean caps aren't the issue too, or am I wrong? We'll see. I'm seeing those TTL adapters, but I'm not so sure which to pick, I never used one of this.

If you see that particular moment, almost all of them will go orange/yellow before the green led, it's wierd, first of all 'cause there are two that aren't doing that. Another mistery to the pile, I guess.


IMO, B is already long, this because I compare it with the others, that's all. Something like K is definitely NECs, and (i.e) starting from B, you can have different behaviours/timing, depending of the caps situation. I'll update what's going on with these consoles once I learn how to do test in the first place lol.

Hmm, I don't think it's as simple as "green light timing = caps state".
My interpretation always was, the YLOD was simply a fail in the bootup sequence. What you'd call POST in computers, a series of checks that everything is OK right before booting.
So more or less, the time at which the YLOD occurs could indicate at which part of the test the system found the error.

To me, the reason that the long (5+ s) YLOD may indicate bad tokins is simply because the check didn't fail at around the 3 second mark where the common RSX checks errors occur, namely 3034 and company.
Then maybe the capacitor fail happens right at the end when the processors are going to start and take current. (Especially the RSX)

This of course is just my ideas (And why I'd still call 4s a shortish ylod. Btw is it always 4? on mine sometimes closer to 2, sometimes closer to 4, normally 3.). But that's why we want to validate with the SYSCON. I ordered also a dongle about a week ago. Hopefully it's a good one, since I chose it a bit blindly hehehe.

About that insignificant Yellow flash at the beginning, well as I said i wouldn't worry. It could even be a camera thing. The framerate syncing with the moment where the RED is turning off and the Green turning on, making yellow for s split second. Again, I would bet you can find that as well in working consoles.

Cheers
 

Attachments

  • 116228726579960899.jpg
    116228726579960899.jpg
    239.8 KB · Views: 44
  • 24456284323485833.jpg
    24456284323485833.jpg
    190.7 KB · Views: 99
I had a 400ms YLOD on PS3#2 (CECHA01). After the SYSCON I performed a "lasterrlog" command and it gave this:
Blue = RSX, Yellow = CELL
Capture3.JPG
RSX&BE.png
Note that the "lasterrlog" wont return this log unless you perform it after the YLOD event while the red light is blinking. Also you need internal command access. From looking at the startup behavior from PS3#3 (working A01) the entire power sequence process takes about half a second:
Blue = RSX, Yellow = CELL
Working_NEC_RSX&BE.png
The last plateou where the CELL voltage decreases seems to be the point where the console has made it past powerup sequence and would start the OS. So if your console has an instant YLOD (<500ms) it could indicate something is wrong in the initial power up sequence. In other words, if the caps were completely bad or missing, it would YLOD in less than half a second. If the BGA were completely buggard or dead, the same. That is the behavior I've seen when the caps are removed or not soldered in properly too. However, PS3#4 had a 1.5s YLOD and returned a similar "lasterrlog":
Lasterrlog.JPG

PS3_4_2.png
I find it interesting that in both cases there is a CELL voltage level increase just before shutdown. The length is the same. I checked this with the working PS3 and if you trigger on the shutdown event the same voltage level increase is seen. So this is normal shutdown behavior.

The plateau before that is where the YLOD event is triggering. Again it occurred in BitTraining, but the reference code is different. My guess is that BitTraining is a process where the CELL BE and RSX co-processors are transferring/comparing data to check if there are any discrepancies. If there are any communication problems it would mean something is preventing the Data from transmitting intact, such as a BGA defect, damaged pad, broken trace on the motherboard, or perhaps a filtering caps that's not working. If it were a filter cap, the noise it's letting through would lead to more intermittent and unpredictable behavior. It perhaps wouldn't affect the exact same thing each time. So maybe we can expect a different BitTraining reference code each time the console experiances a YLOD. I just ran the console again and got the same code, so PS3#4 I strongly suspect is a simple BGA problem, especially since my oscilloscope measurements don't show the waveform on the TOKINs @squeept says is consistent with them being bad. The 3034 error is a general BE Error (CPU), but it has been pointed out to me that an RSX BGA defect can trigger this, I shouldn't immediately assume the CPU needs a reball, and that It usually doesn't.

My point is this. This evidence is consistent with short YLOD being BGA defects. Long YLOD I'm still unsure about. I'd really like to see a "lasterrlog" from one. I'm interested in finding out if the "BitTraining" reference code changes each time the console YLOD. If this is due to a Bad TOKIN, then we might have a way to diagnose a bad tokin with out an oscilloscope! Does anyone have a console with bad tokins or long YLOD that they can SYSCON (preferably someone with an oscilloscpoe to confirm the tokins are bad)? All of mine had short YLOD (<2s).
 
Last edited:
The fan does turn on for a couple seconds, but it is not ramping to jet mode.
This is what an overheat looks like:
See @ElGris post on the previous page for what YLOD looks like:
  • Green LED after touching power on.
  • Yellow LED flashes once.
  • You hear 3 beeps.
  • Console shuts down
  • Red LED flashes indefinitely.
Are you still getting 3 beeps, just not the yellow LED flash? Maybe your power supply is bad or HDD.
 
Definitely not overheating, also not a power supply issue. I put a working psu and still have same symptoms. Red standby light on, press power, get beep, green light for 2 to 3 sec, green changes to red, followed by 3 beeps then flashing red.

Sent from my SM-G965U using Tapatalk
 
My interpretation always was, the YLOD was simply a fail in the bootup sequence. What you'd call POST in computers, a series of checks that everything is OK right before booting.
So more or less, the time at which the YLOD occurs could indicate at which part of the test the system found the error.
Indeed, I believe the same, but I was referring to the exact moment where we should have a normal feeding from the NECs to processors, like it happens with a normal boot. From that moment when everything is ok and NECs are in charge of the boot, we have the last fault of the chain, and the nature of that fault depends of the caps state. I'm not too sure, but I think I read people saying they had even longest YLODs, and that is what I'm talking about. And having our data here, let's put you as an example, you had a L that suddenly died, and you manage to revive it by adding just one tantalum. That YLOD was 5 seconds right? Well, that could be a rule, but IMO we need to see SYSCON to discard any NEC fault, 'cause NECs are tricky, and I believe time could be +-5 seconds, not always just a specific number.

My point is this. This evidence is consistent with short YLOD being BGA defects.
I'm beggining "to believe" lol. Actually that could be a good story to tell, and I'd like it is that real, but only real deployment on the battefield (pcb) against those evil bgas will show us the answer. Sadly.

And it is like you said, the fastest YLODs in my video are those without NECs on, at least, one processor. I guess the rest of the time the PS3 is taking to show a common YLOD is because is doing what you people see with the SYSCON method. And while that, different signals are going through every bga on CELL/RSX, a few by step read, so that explains the different times we get with different consoles.

P/S: I just bought my second dead B. I'm happy and scare at the same time lol.
 
Back
Top