They are 3 small caps, I will say in testing of boot may work without, I can come with those estimated values, yes may get from dia001 if get near value out of board.
I don't want to dissapoint you but if won't work it may need reball, if same status, replace rsx. One question I need to see one photo of cmd with full bringup command if you want to post. I don't want to conclude that is rsx if I don't see SB debugging start message on cmd log. If that work is not an nor corruption/wrong flash. In case you don't see that SB debugging starts it is nor corruption/wrong flash.
Moving one cap, I will assume is 22 nanofarads, probably same value for all. Will reply more later night today if any more requests.
And btw... get used to how your thermal config region looks in a hexeditor by:
1) use the python script to dump the EEPROM
2) compare it with the collection of thermal configs in wiki, there is a high probability that yor thermal config is already in the collection (if not, please advise me and share it to add it to the collection)
3) check the coordinate graphs i made, there are some motherboards missing but if you are lucky it could help you a lot to get an overview of how is configured
4) check the "duty" values for your specific motherboard in your official thermal config, the duty values i was overriding (checking them with a "read" command) was from a DYN-001... if you do the "read" in a different motherboard the official duty values are going to be different
Oh, $h!t, I just remembered I've seen this before! It happened to me while I was thermal testing with webMAN's custom setpoints and using the UART at the same time. I think it has to do with the way webMAN updates and reads thermal data. I remember seeing the CMD terminal was full of thermal monitor calls. Updating every second or so. It was interrupting me from using my own commands, so I turned webMAN off and gave the SYSCON back thermal control.
So it was WMM the responsibly for all that, good to know.
About the 1001 error, any advice on how to proceed?
Changing the CELL tokins can be an option?
I have two other PS3's that need tokins replaced, so I can buy them all together.
About the 1001 error, any advice on how to proceed?
Changing the CELL tokins can be an option?
I have two other PS3's that need tokins replaced, so I can buy them all together.
Yes, current advise is to replace tokins. But again, we're still not sure about 1001.
Here is something I'm working on that provides a potential explanation and alternative approach. But I need help testing it out as consoles with a sole 1001 are hard to come by. This will be in Power Control Topology Part 2...
Adjusting Power Good Threshold
Vid pins VID0-5 on the buck controller form a 6-digit code corresponding to the Vout No load setpoint. Power Good Vmin and Vmax thresholds are relative to that set point. With the stock COK-00X voltage divider values (15K and 20k), Vmin = -163mV. Vmax is always +100mV. The Vout voltage cannot deviate more than that. If it does power good goes low and the SYSCON will error.
In some official SONY refurbished consoles, new resistor values (27K and 10K) change Vmin = -400mV. So the Low Voltage threshold is now more than twice as low, allowing much more voltage ripple before it triggers an error. My hypothesis is SONY did this to reduce the frequency of 1001 and 1002's errors. That would explain why they did it to both buck controllers (CPU and GPU). A sort of admission of guilt that they either set it too aggressively or were compensating for bad NEC/TOKINs without replacing them.
Power good low voltage threshold is there to prevent system instability, but if SONY decided it was okay to loosen it, then perhaps we can follow suit. It could be particularly important because we're seeing a lot of unexplained 1001's recently. Currently, 1002's are assumed to be bad NEC/TOKIN's. Replacing aged bulk filter capacitors certainly works, but just because changing them fixes the error doesn't mean that's the only way to skin a cat.
I have intentionally held off recommending this mod to people, because I'm only freshly aware of it's potential. Before I conclude this is okay to do, I would like to know what the VID at idle is, so we can compare actual voltage measurements with the low voltage threshold. On a console with 1001/1002 errors, Vout should drop more than that before it experiences a YLOD. That means I need oscilloscope measurements of Vout on both the CPU/GPU and PWRGD. Then, by replicating Sony's mod, I would like to see if the error goes away AND the system is stable (requires stress testing)! If so, then we have discovered an easier method of resolving these errors.
Replacing those resistors is fine micro-soldering work that pretty much requires a microscope. And I need oscilloscope measurements of the voltage drop and PWRGD (Cell BE for 1001 and RSX for 1002). So it's not too easy or cheap. I'm not sure how triggering should work, perhaps by selecting a voltage drop larger than the threshold can work. Not sure how to do that.
Right now I have no disk drive or hard drive in the system is that a problem? Also just noticed that the beeper does not appear to work either. It does not beep when pressing the power or eject button.
@poot36 Run bringup once then write bringup again, if no more data it is nor corruption.
See all fine, PCI off does not matter.
Running bringup twice is something that should be noticed as SW models won't load everything in first stage, can't explain how but after second command will show few more details. Add those as well. Can't be sure right now if is software but after more details will be.
Don't bother to solder those missed caps, unless you already did, it may damage something if not doing this often.
Another quick test I would like to test reset image by keeping power button on until you hear one beep(should be 10 seconds) and released, unit should still run on without image but not going to standby.
>$ bringup
00000000
# [SSM] Bringup Start.
# [SSM] PS0 ok.
# [SSM] PS1 ok.
# [SSM] PS2 ok.
>$ bringup
FFFFA605
# [SSM] PS3 ok.
# [SSM] PS4 ok.
# (PowerOn State)
OK 00000000
#!
#!Boot Loader SE Version 3.1.5
#!(Build ID: 3814,43498,
#!Build Date: 2009-12-01_21:11:40)
#!
#!Copyright(C) 2009 Sony Computer Entertainment Inc.All Rights Reserved.
#!
#![INFO]: Connecting to Debug Device (SB UART)
>$
Stays at a blinking cursor. If I hold the power button for 10 seconds when it is on in this state it just powers off. If I then power it back up with the button and keep holding the button after about 6 to 8 seconds the power led that is green flashes and after 10 seconds it still stays on after releasing the button. I never hear it beep at any time in this process. Got any ideas?
#![INFO]: Connecting to Debug Device (SB UART)
Nor is fine.
That is a "special glod" http://s.go.ro/sfhd90xz
Measurements in those photos won't be for your type of board but symptoms are exactly same.
Final state exchange rsx this is my advise.
Buzzer may be damaged ,I've had this in 9 different models,after first 5 or 6 ive understand some slims may have dead/unconnected rsx ram. You have response from syscon,if there was nor wrong flash/corrupiton was not going to show rest of stages from # (PowerOn State)
OK 00000000.
This is on slims,not many ppl fix in my way reballing both cell and rsx .
7 were like that from begining , probably most of the time in droped units.For 2 im not sure what hapened but all exchanged rsx and fine after.
@vyktormvmpay25 I wonder if the buzzer got damaged when the previous repair attempt (where they delided the CPU and RSX). I guess I could try reflowing the RAM chips on the RSX as I don't have anything to loose at this point. I wonder if the RAM chips were damaged due to no thermal paste being used on them. Although the main RSX die does look discolored from heat and looks a blueish color so it may be partially dead in some way.
Hello! I've been reading up on all the awesome progress you all have made over the past few years with SYSCON and reballing/reflow techniques to keep these PS3s running and decided it was a good time to take a peek at one of my parts spares.
Years back, I picked up a CECHA01 that was sold as parts that appeared to be GLOD. I decided to crack it open finally and noticed inside it was in pretty clean/good shape—almost no dust at all. The warranty seal wasn't intact anymore, but it didn't look like anyone made it that far inside of it.
I did a quick re-paste and decided to see what I could get on-screen. Nothing, just a GLOD. Then I tried a couple video resets and suddenly it's producing output. Woohoo!… However, after a few minutes artifacting occurs and it locks up. I restart and artifacts appear shortly after the boot screen. Restart again, GLOD. This is basically the cycle with it now. No video > reset video > maybe it'll output something for a varying amount of time > artifacts and freeze.
So, reading all these threads it sounds a lot like the RSX. I decided to run SYSCON internal and pull the errors.
First, I was surprised to see the system only had 21 days of runtime. But as for the errors, only 3 are reoccurring in the them: 1001, 1701 and 14FF. I was expecting to see something maybe a little more telling (like a 3034 or something else more RSX specific) but these codes seem pretty generic. Is there maybe something more specific about this pattern of error codes that should be pointing me to where I should be looking? Im really thinking my issue is something connection/solder related somewhere though, if not with the RSX itself. I say this because—if I slightly lift up the (horizontal orientation) unit from the bottom front right corner while the artifacts are present and it's frozen, the artifact "pattern" changes.
Hello! I've been reading up on all the awesome progress you all have made over the past few years with SYSCON and reballing/reflow techniques to keep these PS3s running and decided it was a good time to take a peek at one of my parts spares.
Years back, I picked up a CECHA01 that was sold as parts that appeared to be GLOD. I decided to crack it open finally and noticed inside it was in pretty clean/good shape—almost no dust at all. The warranty seal wasn't intact anymore, but it didn't look like anyone made it that far inside of it.
I did a quick re-paste and decided to see what I could get on-screen. Nothing, just a GLOD. Then I tried a couple video resets and suddenly it's producing output. Woohoo!… However, after a few minutes artifacting occurs and it locks up. I restart and artifacts appear shortly after the boot screen. Restart again, GLOD. This is basically the cycle with it now. No video > reset video > maybe it'll output something for a varying amount of time > artifacts and freeze.
So, reading all these threads it sounds a lot like the RSX. I decided to run SYSCON internal and pull the errors.
First, I was surprised to see the system only had 21 days of runtime. But as for the errors, only 3 are reoccurring in the them: 1001, 1701 and 14FF. I was expecting to see something maybe a little more telling (like a 3034 or something else more RSX specific) but these codes seem pretty generic. Is there maybe something more specific about this pattern of error codes that should be pointing me to where I should be looking? Im really thinking my issue is something connection/solder related somewhere though, if not with the RSX itself. I say this because—if I slightly lift up the (horizontal orientation) unit from the bottom front right corner while the artifacts are present and it's frozen, the artifact "pattern" changes.
It is something 1701 that may not easily fix as a result of missing voltage or short circuit, not to jump on conclusions now without further measurements resistance on vdd line for cell and rsx then 4 corners of rsx. Most probably a low resistance in vdd line for cell and from my tests I don't bother to fix 1701. But if someone else here report that error fix somehow, I would like to know how. I'm still learning along with everything and everyone here.
@M4j0r Can you (or anyone) confirm the following logic? Sorry, I know this is complicated. I've been 12hr/daying this for the last 10 days and it's still confusing - Irreducibly complex.
+1.5V_YC_RC_VDDA = "Yellowstone Controller" for XIO / "Redwood Controller" for Rambus FlexIO
It is produced by IC6304 (on COK-00x) and goes through separate filter and bypassing to become...
+1.5V_XDR_YC_VDDA = Yellowstone Memory Interface Controller (MIC) Voltage
+1.5V_RSX_RC_VDDA = Redwood Broadband Engine Interface Controller (BEI) Voltage
These terms are used to denote both the voltages that power the 2x controllers internal to the Cell BE.
YC controls the XIO (extreme I/O) XDR memory interface and RC controls the CPU/GPU FlexIO interface. +1.5V is for the controllers, not the interface! The interfaces (the actual traces) have their own voltage...
+1.2V_YC_RC_VDDIO = CPU Yellowstone XIO & Rambus FlexIO Interface Voltage (the actual traces)
+1.2V_RSX_VDDR = RSX Rambus FlexIO Interface Voltage (the actual traces)
These are produced by IC6303/IC6200) respectively, separate ICs for each? That begs the question. Why? Is it so the the PS3 can power them on sequentially?
Maybe since +1.5V_RSX_VDDIO = VDDP --> DVE/HDMI Encoders, RSX_VDDIO needs 1.2v for it's interface too. So is it possable that, YC_RC_VDDIO or RSX_VDDR is actually for that instead?
That board may value something. Look at tantal caps on cell side, I find those better than others on market, if you to buy new ones now price cross over a faulty units [emoji6]
Ps4 are worst, last night looked at Panasonic "470uf d" 2v, always near 465uf . Those on dyn001 never under 475uf.
Hi, I'm in the middle of fixing another COK-002. When it turns on a YLOD almost instantly shut it down, giving a 3001 error. Swapping PSU makes no difference. Checked all the fuses and tried my best to find shorts, no results. IC6003 does get 12V but it doesn't regulate the voltage so there's no 5V_MISC nor 3.3V_MISC at all, no SW_0 signal from SYSCON either. So finally make me think IC6023 which might be broken. From probing, it always outputs 0V(should stay high as it has a pull-up resistor) which probably the reason forces SYSCON to shutdown the console and not even bother to turn on SW_0 (IC6003).
Question is, where can I get a replacement for IC6003? It's a MITSUMI PST3642UL according to the service manual. I have some donor boards like DIA001 and DIA002 and DYN001. I'm wondering if I can get any same spec chip off them. Thanks!
Maybe since +1.5V_RSX_VDDIO = VDDP --> DVE/HDMI Encoders, RSX_VDDIO needs 1.2v for it's interface too. So is it possable that, YC_RC_VDDIO or RSX_VDDA is actually for that instead?
VDDR is for the Rambus core on all RSX/SB and 65nm or later CELL. The 90nm CELL uses (YC) VDDA for VDDR. It's all really weird since they changed the power system between different revisions, but in general VDDR is for the core, VDDIO for the digitial interface part and VDDA for the analog part.
.
