RCWD21
Member
Do I need to remove the caps to test them or can I test them in circuit? I know certain components need to be out of the circuit to be tested properly.
Sent from my SM-G965U using Tapatalk
PS3 Fault finding YLOD with the SYSCON - First steps and Error reporting
Sent from my SM-G965U using Tapatalk
RIP-Felix
Senior Member
You can't accurately read capacitance of a capacitor in circuit, but you can see if it's shorting. Just check resistance. Some caps have very low resistance and will make your meter buzz if you set it to continuity, so be sure to check the resistance value instead of assuming it's shorting. The NEC/TOKINs for example should have a resistance below 6ohms or so, which will cause your meter to buzz. That's normal. What isn't normal is a reading below 1. That could mean they're shorting/dead, or that the RSX/CPU is dead.
For reference, I was curious to see if known good caps on the RSX and known deficient capacitance on the CPU would cause 1001 errors. Even with 40% of the CPU's capacitcance missing, it didn't error. I just tested PS3#7 (an A model) with 2860uF worth of TaPol on the CPU. This console had previously been reballed and had bad tokins. I removed the tokins and installed 12x470uF TaPol caps on the RSX and 18x 270uF TaPol on the CPU. It was running great. I've been meaning to replace the 18x270uF caps with 12x470uF on the CPU side so that it matches the RSX side. I tested for error after only adding 6x. That's 1940uF under the nominal amount. It ran fine with no errors. The noise was crazy on my scope, but apparently it wasn't enough to cause stability issues. I just installed the rest and it's burning in now. Running good so far.
I don't want to say it's not the tokins, but I would be diligent about checking the VRM and caps around the board before trying the tokins.
For reference, I was curious to see if known good caps on the RSX and known deficient capacitance on the CPU would cause 1001 errors. Even with 40% of the CPU's capacitcance missing, it didn't error. I just tested PS3#7 (an A model) with 2860uF worth of TaPol on the CPU. This console had previously been reballed and had bad tokins. I removed the tokins and installed 12x470uF TaPol caps on the RSX and 18x 270uF TaPol on the CPU. It was running great. I've been meaning to replace the 18x270uF caps with 12x470uF on the CPU side so that it matches the RSX side. I tested for error after only adding 6x. That's 1940uF under the nominal amount. It ran fine with no errors. The noise was crazy on my scope, but apparently it wasn't enough to cause stability issues. I just installed the rest and it's burning in now. Running good so far.
I don't want to say it's not the tokins, but I would be diligent about checking the VRM and caps around the board before trying the tokins.
RCWD21
Member
The part that still gets me is that the only thing that changed was a new laser assembly and being updated to 4.86. Before then it was working wonderfully minus the Blu-ray drive not working.
I'm fixing to check the nec-tokins but given that its reaching a full power on state wouldn't that rule out any bad caps or shorts? I'd think that if it were it would be flashing the yellow light but I could be wrong.
Sent from my SM-G965U using Tapatalk
RCWD21
Member
Ok, so far everything I'm able to check passes. The nec-tokins have a resistance of about 4.6 to 4.8 on all 8 of them. No diodes or caps that I can easily check are shorted or open circuit.
I don't think this is a hardware issue I think its to do with the nand flash given this happened during an update. I'm currently waiting on a few more things to show up to be able to get some dumps from this console.
I also have dumps from a couple of a01 consoles if those can be used to help patch any files.
Sent from my SM-G965U using Tapatalk
I don't think this is a hardware issue I think its to do with the nand flash given this happened during an update. I'm currently waiting on a few more things to show up to be able to get some dumps from this console.
I also have dumps from a couple of a01 consoles if those can be used to help patch any files.
Sent from my SM-G965U using Tapatalk
CodeKiller
Member
If it's FW error, then you should check the SB UART too (and see if goes past lv2)
And also, if the machine is below 3.55, then you can trigger the QA mode with DIY dongle or through syscon somehow(?)
But the VRM error seems more like bad TOKINs to me..
Yes, it can reach full voltage level, but not having enough reserve (capacitance) means when the CPU or the RSX suddenly needs to do stuff, the power surge deplete the caps causing the voltage to drop, then when the VRM controller detects it, sends a power-fail signal to syscon (and shutting down that power-lane?)
RCWD21
Member
I'm horrible with python so I'd need some in depth help with that part on the syscon stuff. But I do have caps (tantalum and new nec-tokins) that I could recap it with and see if that helps.
Sent from my SM-G965U using Tapatalk
RIP-Felix
Senior Member
What hangs me up is you said the console was running fine before the update. The thing is, without a working laser you couldn't have played any games to tax the system, correct? So how do you know the system was fine before the update? The reason this matters is because tokins don't go bad overnight and you would have had stability issues before the update. If the console was solid before the update, then after updating it shouldn't hang for 50s on bootup unless it got corrupted. If the console completed the update successfully, you should be able to get into the recovery menu...but you can't. And if the console is not making it into the XMB after 50s, then it should be stuck in the powerup sequence.
So here's what I think you should do:
Then you could try adding a couple of parasitic TaPol caps and see if the behavior changes.
So here's what I think you should do:
- Gain internal SYSCON access...
- Then flip the PWR rocker to standby. Login to the SYSCON in CXRF mode and use a "bringup" command to power on the console. Wait a few seconds. Then use a "powerstate" command to see whats on. Wait for it to YLOD. Then use a "lasterrlog" command to get specific information about that YLOD.
Then you could try adding a couple of parasitic TaPol caps and see if the behavior changes.
Last edited:
RCWD21
Member
I replaced the laser and was able to load into games one of them was need for speed pro street and the other was i believe call of duty or something along those lines.
It was back to 100% before I attempted the update.
But I'll do my best to get into the syscon and post what I find
Sent from my SM-G965U using Tapatalk
RIP-Felix
Senior Member
Right, and the error codes you posted before were all during power state 80, meaning the powerup sequence completed. That means the bootloader should have started XMB. However, since you still can't get into the XMB, and don't have a 3034, I'm still leaning toward a corrupted update.
Hint, You can copy the contents of the SYSCON to a txt file in notpad, then paste that into the "code" option on the forums. It's located in the reply ribbon under insert. And if you want to keep it clean you can put the code inside a spoiler, which is under insert also...
Hint, You can copy the contents of the SYSCON to a txt file in notpad, then paste that into the "code" option on the forums. It's located in the reply ribbon under insert. And if you want to keep it clean you can put the code inside a spoiler, which is under insert also...
Code:
SYSCON CODE HERE
Pacorretaco
Member
Come on guys this console does not even have a YLOD or beeping. It's shutting down after 50 seconds!
Because of this the errors from the log are all meaningless. (I think I'm having deja vu)
Catching them with bringup would be more helpful.
Good time to try the southbridge uart thingy.
Probably not even a real hardware issue if you say the problem began with a update, and the console is smart enough to shutoff after 50 seconds.
Pacorretaco
Member
Speaking of which... As a matter of fact I just caught a 1002 on a COK 001 board.
Code:
> bringup
bringup
Do nothing. (FatalOff State)
> shutdown
shutdown
[SSM] state: 0600 -> 0000
[SSM] Error state is cleared.
(PowerOff State)
> bringup
bringup
[SSM] state: 0000 -> 0101
Bringup Mode #0 (0xFF)
[SSM] ssmCb_OnStartingBePowOn() called.
[SSM] Bringup mode : syspm_stat=00000000/00000000
[POWSEQ] PowerSeq_Setup called.
[SSM] state: 0101 -> 0201
[POWSEQ] AV Backend Setup
[SSM] state: 0201 -> 0102
[SSM] state: 0102 -> 0202
[SSM] state: 0202 -> 0103
[SSM] fatalreq delayed.
[ERROR]: 0xa0231002
> shutdown
[SSM] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
[SSM] *** Power Fail RS ***
[SSM] state: 0203 -> 0700
[POWSEQ] AV Backend Letup
[SSM] ssmCb_AfterBeOn2() called.
[SSM] Shutdown mode : syspm_stat=00000000/00000000
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)
shutdown
[SSM] state: 0600 -> 0000
[SSM] Error state is cleared.
(PowerOff State)It's not the 80 1002.
It's 23 1002. Meaning I have a ~1s YLOD.
But that's not all the story. I checked voltage with multimeter during that second, and the RSX is getting over 2v!
Sadly this board has signs of previous reflow. But still doesn't look so destroyed to me. CPU and RSX both 2.1 ohm. And this is a 001 board in Europe so it's not like I can call it ugly anyway. Even if it's hiding more problems.
Now, how come there's 2+v DC on the RSX? Nothing's obviously wrong with the RSX power delivery team. But clearly there's something wrong there, also suggested by the 1002 error.
Could be the IC buck power regulator?
No way the tokins are causing that. Or are they?
After all, they are rated 2v. And showing more than 2v. So could be destroyed too even if they weren't causing the fault in the first place.
Still thinking what I should do first, so please advice.
RIP-Felix
Senior Member
I'm gonna disagree with you there. The SYSCON sometimes generates "silent" errors codes - codes that enter the log without an LED. That's how @squeept described the 1001 errors he had with PS3#7 before sending it to me. Some of them might have been him flipping the PWR rocker, but not all of them. And since @RCWD21's console is experiencing "silent" 80 1001, 80 1004, and 80 1701's there could be fire under that smoke.
RCWD21
Member
What would you suggest I do about the caps? Replace them and see if it fully boots? Or see if it throws any different error codes?
Sent from my SM-G965U using Tapatalk
RIP-Felix
Senior Member
I would wait on the tokins for now. We don't want to remove any tokins until we're sure they are bad. Let's gain internal SYSCON acces for now and see if we can trigger those codes again under more controlled conditions...
Capture a "becount" command. I'm just curious to see the usage time. Also, if you could clear the errlof that would be useful, so we know what causes any errors that happen. For example, we know that 1001 and 1004 can be caused by fliping the PWR rocker. So pay attention to that. We want to see if those codes get generated on their own. Then use "bringup" to start the console. "powerstate" to see what's on. Wait for it to shut down on it's own after 50s. Then use "lasterrlog" and "errorlog." Copy all that into notepad and paste into code dialong on the forums. If the codes are the same, there is no harm in adding a few tantalums in parallel to test with (parasite that can be easily removes without removing tokins first).
@Pacorretaco could you do a becount as well? Just curious.
It's normal for the voltage to spike about 150mV above the nominal amount initially upon boot, then regulate down to the right voltage. But that takes about 25ms to resolve. It might be long enough for you meter to briefly flash a voltage above 2v. It's so short a pulse it probably has a hard time resolving it accurately. But if you see the voltage for a few seconds, long enough for the meter to get an accurate fix and refresh a few times with the same reading, then that's a problem.
23 is pretty early in the boot up sequence. PS3#7 had a 10 1002 after I removed the first RSX tokin. It only happened once, while I was getting oscilloscope images. All the rest were 80 1002's. I don't remember how many times I turned the console on/off while gathering the images I needed for the tests, but it was probably around 10 or more. So ~1/10 resulted in an instant YLOD with the 10 1002. That's what can happen with too little capacitance on the RSX. Going further caused 09 3004's and instant YLOD most of the time, although I did get it to POST one 80 1002 in that round of tests. So there is a range where 1002's occur. 09 was 3004. 10 was 1002. you've reported a 23 1002. So it looks like 10 - 80 1002's are possible, depending on when the volltage spike interfered with the startup sequence. If it makes it past boot first and the spike occurs during the bootloader/XMB it'll trigger 80 1002.
RCWD21
Member
Quick question before I start, can I run all these scripts in python on windows 10? I have a separate drive with Linux and python 3.8.5 on it (not sure if that's too late in the line or not and linux is a real pain for me getting everything imported).
Sent from my SM-G965U using Tapatalk
RIP-Felix
Senior Member
Yeah, just DL python for windows. Latest version works with the latest SYSCON script. Check a box during installation to add it to the PATH during installation. Then open a CMD prompt and perform a "pip install pycryptodome". It should inform you of a pip update and give you a command to run it. Then perform a "pip install pyserial". After that, you'll able to use a CMD or windows powershell to do everything. Just remember to change the directory in the first line, then run the script in the second.
Pacorretaco
Member
Here is becount (yeah I don't really like that amount of days)
Also I think @sandungas wanted to see some of this too
Code:
> hversion
hversion
Cok14
> version
version
v1.0.0_k1
[mullion]$
> revision
revision
0B8E
[mullion]$
becount
Bringup : 1416 times
Shutdown: 1157 times
Power-on: 167day 00hour 10min 23sec
[mullion]$
> lasterrlog
lasterrlog
Last Error Code:0xa0231002, Time:0xffffffff
[mullion]$
> eepcsum
eepcsum
Addr:0x000032fe should be 0x52b7
Addr:0x000034fe should be 0x7115
Addr:0x000039fe should be 0x0f38
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff
> patchcsum
patchcsum
r1 csum: [000284EF] [0154FB25] [28F9D2BB]
r2 csum: [0000696B] [00469CF1] [5B6C41AE]
[mullion]$
> patchvereep
patchvereep
major:0x0001
minor:0x0000
patch:0x0000
revision:0x0006
[mullion]$
> patchverram
patchverram
major:0x0001
minor:0x0000
patch:0x0000
revision:0x0006
[mullion]$
>About the 2.3v spike on the RSX... Well all I can say is I measured normal values on CELL using the same method, and also on other boards to see if I was going crazy. But not really. Other boards don't go near or over 2v. This one does, and I think for longer than 25 milliseconds.
Remember I would still be happy with this board even if it turned out to have a very dead RSX... Or things like that. It's a 001 in Europe and I'm doing these things for entertainment mostly. So where others might stop I would be happy to continue even if with less knowledge but more patience and donors. Because yeah I can see this problem is probably not natural, but likely caused by whomever tried to reflow or whatever.
What makes it insteresting is that, once again the tokins are there laughing and teasing...
(1002...) It's like a never ending joke hahaha.
Yeah, you know what I think about that smoke. Is the same smoke that perfectly working consoles are known to throw out. So yeah you're right I can't know there's if there really is no fire... But I can guess.
It's just that I really prefer being wrong than getting exactly into this situation.
Next level would be after the southbridge uart
Last edited:
Similar threads
-
-
PS3 CECHA00 with several SYSCON errors (3004, 1001,1002, 2120,3011)
- Started by LSL
- Replies: 7
-
PS3 Interesting PS3 Errors (1802, 1701, 1601) and Capacitor Replacement- Started by Cheshire UK
- Replies: 2
-