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

Alright I'm on the CMD screen and its not recognizing a thing I type in.

I know I'm on Com port 6 and I need to use CXRF but what do I type in to get to to utilize the script? The tutorial is confusing at this point [emoji52]

Sent from my SM-G965U using Tapatalk
 
Ok I think I'm on the right track? I get the error "scopen response invalid" what do I do now?

** to add to this if I use CXR instead of CXRF I get an auth successful message
Sent from my SM-G965U using Tapatalk
 
Last edited:
So you need to change the eeprom bit to enable internal access mode. Login in as you would normally, in CXR mode. Follow the steps in this quote...
RIP-Felix said:
Okay, internal mode is pretty easy.
  1. AUTH in external CXR mode as normal.
  2. EEP GET 3961 01 --> should return "00000000 FF"
  3. EEP SET 3961 01 00 (changes the bit to allow internal access mode)
  4. EEP GET 3961 01 (verify the change) --> Should now return "00000000 00".
  5. Shut off console & close the CMD prompt/terminal. Connect the Diag wire to GND and turn console back on. It will beep 3 times and start flashing because the checksum doesn't match anymore. This is normal! We're going to fix that next...
  6. You need to use internal command CXRF now. Here's an example of the commands I have to use every time I gain access for a test, but you'll have to change the "COM4" to whichever comm port your usb to serial device was assigned. You can find it under usb devices in the device manager.:
    Code: 
    CD C:\Users\HTPC\Desktop\PS3\SYSCON
python ps3_syscon_uart_script.py COM4 CXRF
  7. AUTH (Uppercase) or auth (lowecase) whichever works. I've had to use both and sometimes is just requires the one or the other. IDK why. Once you get "AUTH successful", you're in!
  8. eepcsum --> will return addresses that "should be" somthing like "0x0038". The address you need to change is the line after the "sum:0x0100" line. The sum indicates the mismatch. Ignore the line before of after, the address you want to change is the one immediately following the sum line. So for example if the that line reads "Addr:0x000039fe should be 0x0038" then you do the following...
  9. w 39fe 38 00 (don't use this command. yours will be different depending on the address that that didn't pass the checksum above. Just put it in like this example, based on your actual checksum mismatch. For example, if your address should be "0xff38" then your command should be "w 39fe 38 ff") --> should just go to the next line or say write successful, I don't remember (you only have to do this once per console). Notice that the 00 and 38 are swapped? That is endian byte swaping and the reason @squeept doesn't like doing this. Dyslexia make this type of thing more confusing than it already is. Anyway that's the hardest part.
  10. r 39fe 02 (validate the change) --> if the checksums match now, then the "sum:0x0100" line will not be there anymore. That means the console will boot normally now.
  11. Turn off the console and turn it on again. The standby led will be solid red and stop flashing. That's because the checksum matches and you successfully gained internal access. Now you need to use step 6 and 7 from now on. You can now use internal commands like "lasterrlog," "bringup," "powerstate," "errlog," and more. enjoy!
Click to expand...
 
Pacorretaco said:
Next level would be after the southbridge uart
Click to expand...
Yeah, that's interesting. I'm curious to see what can be learned from it. New territory to explore! Doesn't the southbridge control USB, HDD, etc? Usually they control BIOS too, yes? I wonder how compartmentalized it is with the SYSCON doing some to the things a traditional SB would. Or does the SYSCON just act as a roadblock, making sure all traffic is authorized. I'm still a noob when it comes to understanding chipsets...lol!
 
RIP-Felix said:
So you need to change the eeprom bit to enable internal access mode. Login in as you would normally, in CXR mode. Follow the steps in this quote...
Click to expand...
Ok so I got the eepcsum and altered the line BELOW the sum which was originally Addr: 0x000039fe should be 0x0f38. I typed in w 39fe 38 ff

It reported w complete [Mullion]

I typed in r 39fe 02 below that it gave me +0 +1 +2 etc and below that it says

38 FF
[mullion]

I typed in eepcsum and now the sum line is 0xf000

Does that seem right?

Sent from my SM-G965U using Tapatalk
 
If you did it right the "sum:0x0100" value should be gone. It will not be there any more. It'll just show a set of addresses.

Based on what you wrote, Addr: 0x000039fe should be 0x0f38." You typed in "w 39fe 38 ff". But what you should have typed in is
w 39fe 38 0f. Was that a mistake or did you actually type it wrong?

No big deal if you did. Just do another write with the correct command and check the sum again.
 
So if your checksum is fixed, you can power off an power back on. From now on you always ground DIAG and login using CXRF.
 
RIP-Felix said:
So if your checksum is fixed, you can power off an power back on. From now on you always ground DIAG and login using CXRF.
Click to expand...
It works! And typing "becount" gives me a bring up of 825 times, a shutdown of 138 times and a power on of 4 hours, 56min and 45 seconds.

From here which commands should I go with? Clearerrlog?

Sent from my SM-G965U using Tapatalk
 
I just tried the get rtc command and I got back RTC Error: battery low occurred, and clock stop occurred.

Would that be something that could cause a firmware update to go screwy and corrupt?

Sent from my SM-G965U using Tapatalk
 
Maybe, interesting. At least now you know the RTC batt needs changed.

First lets get the lasterrlog and errlog recorded.

Then clearerrlog
Followed by bringup, which will start the console.
After a few seconds powerstate.
Wait for the console to shutdown on it's own as it has been....

Then, lasterrlog and errlog again.

Then press CTRL+A to highlight the text in the CMD widow and CTRL+C to copy it. Paste that into a code dialong here.
 
RCWD21 said:
It works! And typing "becount" gives me a bring up of 825 times, a shutdown of 138 times and a power on of 4 hours, 56min and 45 seconds.
Click to expand...
That's a very low usage console, I wouldn't expect to see tokin or BGA wearing out so soon! However, if it was used in a supercomputer array performing numbercrunches all day and never shutdown, then when it overheated or had a power outage it doesn't add that time to the record. It only records the on time at shutdown, if it was properly shutdown. EDIT: I suspect that is the case since there is such a different number of pwr on's vs pwr offs. If it was safely shutdown as many times as it was PWR'ed on, it'd have the same number. So your console has 687 sessions where it was not recording how long it was on.
 
Errlog is the same codes as the codes I posted previously 801001,1004, and 1701 only.

Lasterrlog is showing the 801001 code.

Sent from my SM-G965U using Tapatalk
 
Would you please post the code, I want to see the timestamps. EDIT: The lasterrlog would show which step in the startup sequence it got hung up on, unless it made POST, which it should have given the 80 power state on the error.
 
Last edited:
Heres the errlog with time stamps.


>$ errlog
errlog
ofst[ 76]:err_code:0xffffffff, clock:0x1065ca0f 2008/09/19 02:25:19
ofst[ 80]:err_code:0xa0801004, clock:0x1066d48f 2008/09/19 21:22:23
ofst[ 84]:err_code:0xa0801004, clock:0x10671038 2008/09/20 01:36:56
ofst[ 88]:err_code:0xa0801001, clock:0x10693fff 2008/09/21 17:25:19
ofst[ 92]:err_code:0xa0801001, clock:0x10695494 2008/09/21 18:53:08
ofst[ 96]:err_code:0xa0801004, clock:0x1069559e 2008/09/21 18:57:34
ofst[100]:err_code:0xa0801004, clock:0x106955d0 2008/09/21 18:58:24
ofst[104]:err_code:0xa0801001, clock:0x106958a1 2008/09/21 19:10:25
ofst[108]:err_code:0xa0801004, clock:0x10697dda 2008/09/21 21:49:14
ofst[112]:err_code:0xa0801004, clock:0x107032f7 2008/09/26 23:55:35
ofst[116]:err_code:0xa0801004, clock:0x10703413 2008/09/27 00:00:19
ofst[120]:err_code:0xa0801001, clock:0x10716c0b 2008/09/27 22:11:23
ofst[124]:err_code:0xa0801004, clock:0x10716d9e 2008/09/27 22:18:06
ofst[ 0]:err_code:0xa0801004, clock:0x10716e6c 2008/09/27 22:21:32
ofst[ 4]:err_code:0xa0801001, clock:0x107815ea 2008/10/02 23:29:46
ofst[ 8]:err_code:0xa0801001, clock:0x10d6fe2d 2008/12/13 23:13:49
ofst[ 12]:err_code:0xa0801001, clock:0x1d0dd56a 2015/06/12 17:37:46
ofst[ 16]:err_code:0xa0801001, clock:0x1d0ddd2e 2015/06/12 18:10:54
ofst[ 20]:err_code:0xa0801004, clock:0x25d58701 2020/02/11 15:38:41
ofst[ 24]:err_code:0xa0801004, clock:0x25d598ba 2020/02/11 16:54:18
ofst[ 28]:err_code:0xa0801001, clock:0x26045d59 2020/03/18 04:17:29
ofst[ 32]:err_code:0xa0801004, clock:0x26047a16 2020/03/18 06:20:06
ofst[ 36]:err_code:0xa0801001, clock:0x27169f12 2020/10/12 04:58:58
ofst[ 40]:err_code:0xa0801001, clock:0x2716a2ad 2020/10/12 05:14:21
ofst[ 44]:err_code:0xa0801001, clock:0x2716ac2c 2020/10/12 05:54:52
ofst[ 48]:err_code:0xa0801701, clock:0x2716aeac 2020/10/12 06:05:32
ofst[ 52]:err_code:0xa0801701, clock:0x2717b0d7 2020/10/13 00:27:03
ofst[ 56]:err_code:0xa0801001, clock:0x2717b11a 2020/10/13 00:28:10
ofst[ 60]:err_code:0xa0801001, clock:0x2717b714 2020/10/13 00:53:40
ofst[ 64]:err_code:0xa0801001, clock:0xffffffff
ofst[ 68]:err_code:0xa0801001, clock:0xffffffff
ofst[ 72]:err_code:0xa0801001, clock:0xffffffff
[mullion]$
 
And here is the bring up and powerstate commands. I noticed that "PCI Power"
is off. Is that normal?

>$ 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] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
[SSM] state: 0203 -> 0104
Psbd_SbTransMode_Half:0x20e2
>$ powerstate
[SSM] state: 0104 -> 0204
[SSM] state: 0204 -> 0105
[SSM] state: 0105 -> 0400
(PowerOn State)
[SERV NVS] READ CMD
Boot Loader SE Version 0.9.5 (Build ID: 1634,16289, Build Data: 2006-09-21_19:11:09)
Copyright(C) 2006 Sony Computer Entertainment Inc.All Rights Reserved.
[SERV SETCFG] XDR (CH0,CH1) ASSERT
[SERV SETCFG] XDR (CH0,CH1) DEASSERT
[INFO]: Connecting to Debug Device (SB UART)
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV THERM] NOTIFY_MODE CMD
[SERV NOTIF] CONTROL_LED
[SERV NOTIF] RING_BUZZER
[SERV NOTIF] CONTROL_LED
powerstate
ATA Power : ON
PCI Power : OFF
RSX Power : ON
XDR Power : ON
Eurus Power : ON
SB Power : ON
RSX Thermal Sensor : AVAILABLE
BE Thermal Sensor : AVAILABLE
[mullion]$
 
Pacorretaco said:
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.
After 200 pages of tokin thread and 50 pages of this one, our computer is surely even bigger than that one hahaha.

Next level would be after the southbridge uart
Click to expand...
I don't really know what to say exactly as if those resistance are so low probably that 2v for 1 second is resulting a spike while any cpu are rsx trying to absorb power from power supply.
Its likely in electric short circuit where amps of shorts gets a bigger value with at least 5 times more than normal functionality.
So quite same situation but on small level. That's why nec's and coil and those bigger resistance are actually "rlc filters" which should limit voltage/amps on short/high overhead voltage.
Longer explication, just on your case I'm thinking of one thing if you want to test and see if it is possible to change the state of unit. Simply remove those 3 big grey resistors before nec's. It should give same errors 1001. It only way to separate power line from cpu/rsx and get a real resistance from ic or resistance of power lines.
Do clear error log and see bring up.
If you can do this with small heat gun set at 250 and debit air at level 2~3. While heat cover nec's and cpu/gpu. In same time add leaded alloy with soldering iron set at 350~400 on legs of that resistance. It should go ot in a minute. If not increase hot air at 300 and work with both in same time air and soldering iron. This should not affect nec's or cpu/gpu if you cover with aluminium foil tape or similar foil.
Remember you work more with iron and heat each leg at 5 seconds, while air is on part, at one point of cumulated temp that resistance will be removed.
It won't change that error but I'm thinking a better way to get resistance from cpu/gpu.
Now second stage if you have one capacity meter that can take 20 milifarads will be helpful. On slims I think I've seen around 10 can't remember now. They are all in parallel and counting all small together, not sure now.
Anyway should be more than 2500microfarad.
Anyway those ic on board and out should be 3 ohms or very near. What is under 2.5 I don't expect to be repaired or if it will work in XMB it will fail in games.Or will get over normal temperatures with 10 then usually. Seen to many situations around 2012.
An effort to reball is not necessarily.
If you get confused ask each step. In reball thread.
I have not performed this test on phats but was about to start on. I really hate phats boards and if I don't like something that won't work easy for me.
 
RCWD21 said:
And here is the bring up and powerstate commands. I noticed that "PCI Power"
is off. Is that normal?

>$ 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] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
[SSM] state: 0203 -> 0104
Psbd_SbTransMode_Half:0x20e2
>$ powerstate
[SSM] state: 0104 -> 0204
[SSM] state: 0204 -> 0105
[SSM] state: 0105 -> 0400
(PowerOn State)
[SERV NVS] READ CMD
Boot Loader SE Version 0.9.5 (Build ID: 1634,16289, Build Data: 2006-09-21_19:11:09)
Copyright(C) 2006 Sony Computer Entertainment Inc.All Rights Reserved.
[SERV SETCFG] XDR (CH0,CH1) ASSERT
[SERV SETCFG] XDR (CH0,CH1) DEASSERT
[INFO]: Connecting to Debug Device (SB UART)
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV THERM] NOTIFY_MODE CMD
[SERV NOTIF] CONTROL_LED
[SERV NOTIF] RING_BUZZER
[SERV NOTIF] CONTROL_LED
powerstate
ATA Power : ON
PCI Power : OFF
RSX Power : ON
XDR Power : ON
Eurus Power : ON
SB Power : ON
RSX Thermal Sensor : AVAILABLE
BE Thermal Sensor : AVAILABLE
[mullion]$
Click to expand...
That's all normal, as expected. So the console is booting and everything that's supposed to be powered on is. The console should be in XMB and displaying. What do you get when you plug in AV cable?
 
You must log in or register to reply here.

Similar threads

Back
Top