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

[Jeff The Animal]

Im working on a 2500 slim model with JTP-001 board with GLOD, the console had liquid damage signs all over, even on main power supply.
Hdmi IC was bad, removed.
GLOD still persists, brain dead, controls dont sync nor charge, eject button responds, digital audio LED just blinks once console is turned on, power button doenst repond to try to reset video etc, if pressed long enough console just turns off.
CELL gets hot with time, and if no heatsink/cooler present it turns off by overheating.
maybe SB or CELL bad?

Heres the errlog i got:

Spoiler: Error Log

>$ auth
Auth successful
>$ errlog
00000000
# CODE CLOCK
# A0802024 FFFFFFFF
# A0802124 FFFFFFFF
# A0002124 FFFFFFFF
# A0902024 FFFFFFFF
# A0902024 FFFFFFFF
# A0902024 FFFFFFFF
# A0802124 FFFFFFFF
# A0902124 FFFFFFFF
# A0902024 FFFFFFFF
# A0902024 FFFFFFFF
# A0902024 FFFFFFFF
# A0802024 FFFFFFFF
# A0802124 FFFFFFFF
# A0902124 FFFFFFFF
# A0902024 FFFFFFFF
# A0902024 FFFFFFFF
# A0902024 FFFFFFFF
# A0802024 FFFFFFFF
# A0802124 FFFFFFFF
# A0A02124 FFFFFFFF
# A0A02024 FFFFFFFF
# A0A02024 FFFFFFFF
# A0A02024 FFFFFFFF
# A0802024 FFFFFFFF
# A0802124 FFFFFFFF
# A0002024 FFFFFFFF
# A0902024 FFFFFFFF
# A0902024 FFFFFFFF
# A0902024 FFFFFFFF
# A0802024 FFFFFFFF
# A0802124 FFFFFFFF

>$ version
00000000
# Sherwood Version = 1.21.0

>$ bringup
00000000
# [SSM] Bringup Start.

>$ powerstate
00000000
# [SSM] PS0 ok.
# [SSM] PS1 ok.
# [SSM] PS2 ok.
# [SSM] PS3 ok.
# [SSM] PS4 ok.
# (PowerOn State)
OK 00000000
#!
#!Boot Loader SE Version 3.4.0
#!(Build ID: 3932,45679,
#!Build Date: 2010-06-07_23:08:10)
#!
#!Copyright(C) 2010 Sony Computer Entertainment Inc.All Rights Reserved.
#!
#![INFO]: Connecting to Debug Device (SB UART)
# ATA :ON
# PCI :OFF
# PCIex:OFF
# RSX :ON
# GDDR :ON
# XDR :ON
# EURUS:ON
# SB :ON
# LAN :ON
# WLAN :ON

>$ shutdown
00000000
# [SSM] Shutdown Start.
# [SSM] Shutdown ok.
# (PowerOff State)
OK 00000000

 

[sandungas]

Im working on a 2500 slim model with JTP-001 board...

Please, please, please, can you run the command ">$ r A0250 200" and paste the result in the forum?, is for a good cause

Is pretty much the same i asked to @Kleon1876 in this post, but using a different address because the syscon you have in the JTP-001 motherboard belongs to the "sherwood" familly
https://www.psx-place.com/threads/f...and-error-reporting.30100/page-40#post-287667

In other words... im asking you to make a dump of an area named "thermal config", but is located at a different address
And to be honest... im not completly sure if the adress A0250 im suggesting to use is correct
If you are worrying about posting some unique key or identifyer of that console just because we are doing the dump at an incorrect address just use this command instead ">$ r A0250 10"
This is going to display only 16 bytes, but is going to be enought for me and others to identify if is actually the start of the "thermal config" area for sherwood syscons

 

[sandungas]

The problem is the sherwood syscons are using a "virtual map" for the "rewritable" area
When you acess it the data by UART you are accesing it by the adresses of the virtual map (but the data icould be lcoated anywhre, or not contiguosly)

I think is better to ask directly to @M4j0r ... can you tell us the exact command to make a dump of 0x200 bytes from the start of the "thermal config" area ?

 

[Jeff The Animal]

Please, please, please, can you run the command ">$ r A0250 200" and paste the result in the forum?, is for a good cause

Is pretty much the same i asked to @Kleon1876 in this post, but using a different address because the syscon you have in the JTP-001 motherboard belongs to the "sherwood" familly
https://www.psx-place.com/threads/f...and-error-reporting.30100/page-40#post-287667

In other words... im asking you to make a dump of an area named "thermal config", but is located at a different address
And to be honest... im not completly sure if the adress A0250 im suggesting to use is correct
If you are worrying about posting some unique key or identifyer of that console just because we are doing the dump at an incorrect address just use this command instead ">$ r A0250 10"
This is going to display only 16 bytes, but is going to be enought for me and others to identify if is actually the start of the "thermal config" area for sherwood syscons

i can try it yes, but can only work on it at night time and weekends, i will try to get it tonight.
But it is straithforward or need to some more modfication and stuff? im only using tx/rx on the board.
im more of eletronics guy, code is not my strong side, so i will need instructions if need to do more. Dont know abou ID and all, but if you think is safe i post here, otherwise i can send you a PM with the info.
just for info: i did try to run more commands but most of them didnt work (becount, lasterrlog etc).

anyway, will try and let you know how it goes...

 

[Pacorretaco]

i can try it yes, but can only work on it at night time and weekends, i will try to get it tonight.
But it is straithforward or need to some more modfication and stuff? im only using tx/rx on the board.
im more of eletronics guy, code is not my strong side, so i will need instructions if need to do more. Dont know abou ID and all, but if you think is safe i post here, otherwise i can send you a PM with the info.
just for info: i did try to run more commands but most of them didnt work (becount, lasterrlog etc).

anyway, will try and let you know how it goes...

Your syscon RX and tx connection you already have should be enough.

becount and lasterrlog (even getrtc among others) are not working on SW mode because it's not exactly the same as with the older models. The commands are still there but
These are actually "internal commands" and the SW mode you are using isn't quite having internal permissions, unlike CXRF for example. Thankfully most of the other useful commands are already available directly without requiring this internal access.

I'm sure somebody can explain it better than me hehehe

 

[sandungas]

i can try it yes, but can only work on it at night time and weekends, i will try to get it tonight.
But it is straithforward or need to some more modfication and stuff? im only using tx/rx on the board.
im more of eletronics guy, code is not my strong side, so i will need instructions if need to do more. Dont know abou ID and all, but if you think is safe i post here, otherwise i can send you a PM with the info.
just for info: i did try to run more commands but most of them didnt work (becount, lasterrlog etc).

anyway, will try and let you know how it goes...

Better wait a bit, now that i summoned @M4j0r the next time he joins the forum he will tell us the correct command to dump the thermal config area in sherwoods

The command is going to display around 30 lines with bytes and you can copypaste them as text to the forum in the same way you did with other commands

The commands you tryed and was not working i guess is either because requires special permissions, or because was removed from the firmware, in this link there are some lists of the commands for sherwoods
https://www.psdevwiki.com/ps3/System_Controller_Firmware#Command_list_.28Sherwood.29

There is no info or notes about sherwoods commands in the lists... you need to read info in the other command list for mullion (the old syscons) in the same wiki page as a reference
In general... most of commands have the same name and works in the same way

 

[TimeWalker75a]

Now that I'm back from my (hospital) hiatus ..

It occurs to me that you don't have the schematic. @vyktormvmpay25 posted a link to them here. Anyways that is IC2408, a DC-DC converter that converts 3.3v_MISC (Vin pin7) to 1.8v_ANA (Vout pin1). I'm guessing "ANA" stands for analog, but I'm not sure. Pin 2 is NC and Pin 3 is GND. It's not good to leave NC's floating, so it was probably tied to GND. C2460 connects pin 4 (CN) to GND, so it may have low resistance and trip your continuity buzzer, but it should read a resistance value greater than a short. So double check that it is actually shorting before you replace.

Cheers for the diagram pointer, I do have a service manual PDF for COK-002 on hand but I'm so far rubbish in reading it, heh.
Have gone over JL points documented and they appear to read fine. So .. moving onto something else.

Judging from
[ERROR]: 0xb0002001 (FATAL) XDR Link not initilized.

Error message, possible faulty RAM near the cell chip.

Is there any sensible way to tell that a particular chip out of the 4 is dead? I've managed to get ahold of a spare COK-002w board that seems to have even more of a filthy history, so if needs be I can at least get a chip or two replaced.

 

[M4j0r]

The problem is the sherwood syscons are using a "virtual map" for the "rewritable" area
When you acess it the data by UART you are accesing it by the adresses of the virtual map (but the data icould be lcoated anywhre, or not contiguosly)

I think is better to ask directly to @M4j0r ... can you tell us the exact command to make a dump of 0x200 bytes from the start of the "thermal config" area ?

It's located at 0x200 (length 0x200).
So you would run something like "EEP GET 0200 40", "EEP GET 0240 40", ....

 

[sandungas]

It's located at 0x200 (length 0x200).
So you would run something like "EEP GET 0200 40", "EEP GET 0240 40", ....

Hmm, some questions:

You are suggesting to use the "EEP" command because he "r" command is locked in sherwoods ?
In theory is posible to unlock the "r" command by patching the syscon firmware ?
The restriction about reading data in chunks of 0x40 lenght is something specific of the EEP command or aplyes to all other commands in sherwoods ?
If at some point are published the patches to unlock other sherwood commands we are going to be able to do a "r" command and read a chunk of data of 0x200 bytes in a single stream ?

 

[M4j0r]

You are suggesting to use the "EEP" command because he "r" command is locked in sherwoods ?

You can use both, but EEP does have a bigger buffer.

In theory is posible to unlock the "r" command by patching the syscon firmware ?

No need to, it's already unlocked (just need the auth, but that's the same for EEP). Only the "INT" commands need a patch.

The restriction about reading data in chunks of 0x40 lenght is something specific of the EEP command or aplyes to all other commands in sherwoods ?

Just the EEP command. Others vary - doesn't really make sense.

If at some point are published the patches to unlock other sherwood commands we are going to be able to do a "r" command and read a chunk of data of 0x200 bytes in a single stream ?

You can just use python to automate the task (https://www.psdevwiki.com/ps3/Talk:SC_Communication#Example_Scripts), Sherwood is also way slower than Mullion.


About the modes:
The syscon originally only had a closed and opened mode (on the prototypes), this means e.g. "version" (closed) and "r" (opened). But they also called it external/internal mode.
At some time (probably around 0.90) they added on Cookie the "external interface" with the uppercase commands like "EEP" (excluding "LS"). So now you have unauthenticated and authenticated external and internal mode ("VER" vs "EEP" vs "version" vs "r").
On Sherwood they changed the names again, now the external and the Cookie internal mode have been merged and they added "new" internal commands (INT - which need the firmware patch).
These mode names are all from Sony and are not very consistent.
So I just use external mode for the uppercase commands (excl. "LS") and internal mode for the lower case commands on Mullion and on Sherwood there's no difference between these - the "new internal commands" can't be accessed without a patch.

 

[Pacorretaco]

Hm, and this procedure can be done in reverse?
Writing that whole area in one go with another thermal config which was obtained that way, maybe edited manually.
(Then fixing the checksum)
And if something goes wrong, the original dumped settings could just be written back again

Or it would be too much writing for a single write command?
I'm trying to understand how to easily modify the syscon fan curves.

Thank you

 

[sandungas]

Those temperatures are good!

Could you please elaborate on the process of tweaking the syscon fan tables?
What about the SW syscons like L model? The checksums behave differently don't they?

This is something that can help anybody. Not just technicians
Until now I've been more or less OK with webman fan control, but syscon is way superior

I have lot of doubts so maybe some of the things im going to say are not much accurate, but just to keep this talk active...

The sherwood syscons doesnt contains a checksum at the end of the "thermal config" area. And the UART interface doesnt have either a "internal mode "or "external mode" (there is only one mode)... so in that matter is easyer to deal with them

The area named "thermal config" i was talking about contains hundreds of settings that can be modifyed individually by other commands, e.g. with the command "fantbl" you can change 3 values inside the "thermal config" area in a single action

 Usage: fantbl set fanconNo pNo tempD tempU duty
      ex. fantbl set 0 p1 0x1400 0x1E40 0xC0

There are a bunch of other commads to change individual values inside the "thermal config" area (such "tshutdown", "tshutdowntime", "fanconpolicy", "hyst", etc...)
So... you can start using all that commands to start configuring things individually... or (the best option in my oppinion)... you can prepare the whole data of the "thermal config" area (0x200 bytes) with custom valules in your PC in a hexeditor and then overwrite it completly, this way you are changing hundreds of values in a single action

There is something i could not understand well, inside the "thermal config" area there are some values that indicates if the data is loaded from syscon ROM or from syscon RAM
The changes we make to syscon RAM are volatile, only valid for the current session, if you cut power to syscon it resets, this is good for testing thermal profiles

 

[TimeWalker75a]

DIA-001, CECHH03, a very quick half a second YLOD.

Not sure what to make of the 80 (PowerOn) state 1002 errors in the log, does that still fall under the suspicion of NEC/Token on RSX? As for the latter 2102, quickly swapped IC6301 from another board, as per OP indication, the code persisted. Don't have multi-meter probes thin enough to poke at the pins on that TI 5233 IC directly and being a DIA-001 not sure of the test points either, are they any similar to SEM-001 perhaps? Yes, the CMOS battery is completely dead at this point, so not sure when that thing "transitioned".

errlog
ofst[  4]:err_code:0xffffffff, clock:0x0b740c86  2006/02/02 00:19:18
ofst[  8]:err_code:0xa0801002, clock:0x0b740c8d  2006/02/02 00:19:25
ofst[ 12]:err_code:0xa0801002, clock:0x0b740c95  2006/02/02 00:19:33
ofst[ 16]:err_code:0xa0801002, clock:0x0b740c9f  2006/02/02 00:19:43
ofst[ 20]:err_code:0xa0801002, clock:0x0b740ca9  2006/02/02 00:19:53
ofst[ 24]:err_code:0xa0801002, clock:0x0b740cb2  2006/02/02 00:20:02
ofst[ 28]:err_code:0xa0801002, clock:0x0b740cbc  2006/02/02 00:20:12
ofst[ 32]:err_code:0xa0801002, clock:0x0b740cc9  2006/02/02 00:20:25
ofst[ 36]:err_code:0xa0801002, clock:0x0b740cd3  2006/02/02 00:20:35
ofst[ 40]:err_code:0xa0801002, clock:0x0b740cef  2006/02/02 00:21:03
ofst[ 44]:err_code:0xa0902120, clock:0x0b740cef  2006/02/02 00:21:03
ofst[ 48]:err_code:0xa0801002, clock:0x0b740cf8  2006/02/02 00:21:12
ofst[ 52]:err_code:0xa0801002, clock:0x0b7ac11f  2006/02/07 02:23:27
ofst[ 56]:err_code:0xa0801002, clock:0x0b7ac143  2006/02/07 02:24:03
ofst[ 60]:err_code:0xa0801002, clock:0x0b7ac14e  2006/02/07 02:24:14
ofst[ 64]:err_code:0xa0801002, clock:0x0b7ac16c  2006/02/07 02:24:44
ofst[ 68]:err_code:0xa0801002, clock:0x0b7ac17a  2006/02/07 02:24:58
ofst[ 72]:err_code:0xa0801002, clock:0x0b7d8b5a  2006/02/09 05:10:50
ofst[ 76]:err_code:0xa0801002, clock:0x0b7d8b90  2006/02/09 05:11:44
ofst[ 80]:err_code:0xa0801002, clock:0x0b7d8bcd  2006/02/09 05:12:45
ofst[ 84]:err_code:0xa0801002, clock:0x0b7d8c2f  2006/02/09 05:14:23
ofst[ 88]:err_code:0xa0801002, clock:0x0b7d8c55  2006/02/09 05:15:01
ofst[ 92]:err_code:0xa0801002, clock:0x0b7d8f69  2006/02/09 05:28:09
ofst[ 96]:err_code:0xa0801002, clock:0x0b7d8f8a  2006/02/09 05:28:42
ofst[100]:err_code:0xa0801002, clock:0x0b82522b  2006/02/12 20:08:11
ofst[104]:err_code:0xa0801002, clock:0x0b825243  2006/02/12 20:08:35
ofst[108]:err_code:0xa0801002, clock:0x0b825255  2006/02/12 20:08:53
ofst[112]:err_code:0xa0801002, clock:0x0b89d5fe  2006/02/18 12:56:30
ofst[116]:err_code:0xa0232102, clock:0xffffffff
ofst[120]:err_code:0xa0232102, clock:0xffffffff
ofst[124]:err_code:0xa0232102, clock:0xffffffff
ofst[  0]:err_code:0xa0232102, clock:0xffffffff

>$ version
version
v1.3.3_k1

>$ bringup
bringup
[SSM] state: 0000 -> 0101
Bringup Mode #0 (0xFF)
[SSM] ssmCb_OnStartingBePowOn() called.
[SSM] First Boot.
[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 -> 0303
[SSM] PowSeq Fail : Detected !
[SSM] state: 0303 -> 0700
[POWSEQ] AV Backend Letup
[SSM] Shutdown mode : syspm_stat=00000000/00000000
[ERROR]: 0xa0232102
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)

lasterrlog
Last Error Code:0xa0232102, Time:0xffffffff

 

[sandungas]

You can use both, but EEP does have a bigger buffer.

To be honest, i dont understand which negative consequences could result from a shorter buffer
In this case that we are dumping only 0x200 bytes looks convenient to use this command

">$ r 200 200"

Just the EEP command. Others vary - doesn't really make sense.

Ok, i was thinking if the restriction to data chunks of 0x40 was something generic, lets say... a consequence of the virtual map, or just because the special FLASH area inside sherwoods required to access it that way... so all the commands was going to be affected by this restriction of chunks of 0x40 bytes
But now i got it, is a restriction of how is implemented the EEP command

You can just use python to automate the task (https://www.psdevwiki.com/ps3/Talk:SC_Communication#Example_Scripts), Sherwood is also way slower than Mullion.

An script to dump (and to write) the entire "thermal config" area with the EEP command could be handy
But by now i think the "r" command is good enought for dumping, and for writing... well thats another story more risky

Eventually could be implemented in the program made by @Sweetdude26 that allows to do stuff clicking in buttons with a mouse, this features to deal with the thermal config would be a nice addition to the program imo
https://github.com/db260179/ps3syscon/tree/master/SysconReader

About the modes:
The syscon originally only had a closed and opened mode (on the prototypes), this means e.g. "version" (closed) and "r" (opened). But they also called it external/internal mode.
At some time (probably around 0.90) they added on Cookie the "external interface" with the uppercase commands like "EEP" (excluding "LS"). So now you have unauthenticated and authenticated external and internal mode ("VER" vs "EEP" vs "version" vs "r").
On Sherwood they changed the names again, now the external and the Cookie internal mode have been merged and they added "new" internal commands (INT - which need the firmware patch).
These mode names are all from Sony and are not very consistent.
So I just use external mode for the uppercase commands (excl. "LS") and internal mode for the lower case commands on Mullion and on Sherwood there's no difference between these - the "new internal commands" can't be accessed without a patch.

Ok, i see a bit of the mess of official names, the UART terminal (where we write commands) is actually an external interface (terminal)... and with it we can authentificate to syscon software as external or internal mode
The "EEP GET" is equivalent to "r", and "EEP SET" to "w"

 

[M4j0r]

To be honest, i dont understand which negative consequences could result from a shorter buffer
In this case that we are dumping only 0x200 bytes looks convenient to use this command

">$ r 200 200"

Well, this has something to do with the limited RAM, it doesn't just straight write the eeprom contents to the serial port.
Yes, in theory you can patch it , but it doesn't really make sense since it's not way faster than just calling the command multiple times.
The CELL <-> SC SPI interface is even more limited in terms of these sizes.

 

[Pacorretaco]

So, what is the "size" of the chunks that can be written in one operation using either EEP SET or "w" commands?

Is it enough to be able to easily write/restore the whole thermal config area from the dump made with EEP GET or "r" commands for example?

This would make it easier to tinker with these things I suppose.

 

[M4j0r]

So, what is the "size" of the chunks that can be written in one operation using either EEP SET or "w" commands?

EEP GET/SET 0x40 bytes, for w it's platform specific but always less.
There's also a write example here: https://www.psdevwiki.com/ps3/Talk:SC_Communication#Example_Scripts (last example).

 

[RIP-Felix]

DIA-001, CECHH03, a very quick half a second YLOD.

Not sure what to make of the 80 (PowerOn) state 1002 errors in the log, does that still fall under the suspicion of NEC/Token on RSX? As for the latter 2102, quickly swapped IC6301 from another board, as per OP indication, the code persisted. Don't have multi-meter probes thin enough to poke at the pins on that TI 5233 IC directly and being a DIA-001 not sure of the test points either, are they any similar to SEM-001 perhaps? Yes, the CMOS battery is completely dead at this point, so not sure when that thing "transitioned".

errlog
ofst[  4]:err_code:0xffffffff, clock:0x0b740c86  2006/02/02 00:19:18
ofst[  8]:err_code:0xa0801002, clock:0x0b740c8d  2006/02/02 00:19:25
ofst[ 12]:err_code:0xa0801002, clock:0x0b740c95  2006/02/02 00:19:33
ofst[ 16]:err_code:0xa0801002, clock:0x0b740c9f  2006/02/02 00:19:43
ofst[ 20]:err_code:0xa0801002, clock:0x0b740ca9  2006/02/02 00:19:53
ofst[ 24]:err_code:0xa0801002, clock:0x0b740cb2  2006/02/02 00:20:02
ofst[ 28]:err_code:0xa0801002, clock:0x0b740cbc  2006/02/02 00:20:12
ofst[ 32]:err_code:0xa0801002, clock:0x0b740cc9  2006/02/02 00:20:25
ofst[ 36]:err_code:0xa0801002, clock:0x0b740cd3  2006/02/02 00:20:35
ofst[ 40]:err_code:0xa0801002, clock:0x0b740cef  2006/02/02 00:21:03
ofst[ 44]:err_code:0xa0902120, clock:0x0b740cef  2006/02/02 00:21:03
ofst[ 48]:err_code:0xa0801002, clock:0x0b740cf8  2006/02/02 00:21:12
ofst[ 52]:err_code:0xa0801002, clock:0x0b7ac11f  2006/02/07 02:23:27
ofst[ 56]:err_code:0xa0801002, clock:0x0b7ac143  2006/02/07 02:24:03
ofst[ 60]:err_code:0xa0801002, clock:0x0b7ac14e  2006/02/07 02:24:14
ofst[ 64]:err_code:0xa0801002, clock:0x0b7ac16c  2006/02/07 02:24:44
ofst[ 68]:err_code:0xa0801002, clock:0x0b7ac17a  2006/02/07 02:24:58
ofst[ 72]:err_code:0xa0801002, clock:0x0b7d8b5a  2006/02/09 05:10:50
ofst[ 76]:err_code:0xa0801002, clock:0x0b7d8b90  2006/02/09 05:11:44
ofst[ 80]:err_code:0xa0801002, clock:0x0b7d8bcd  2006/02/09 05:12:45
ofst[ 84]:err_code:0xa0801002, clock:0x0b7d8c2f  2006/02/09 05:14:23
ofst[ 88]:err_code:0xa0801002, clock:0x0b7d8c55  2006/02/09 05:15:01
ofst[ 92]:err_code:0xa0801002, clock:0x0b7d8f69  2006/02/09 05:28:09
ofst[ 96]:err_code:0xa0801002, clock:0x0b7d8f8a  2006/02/09 05:28:42
ofst[100]:err_code:0xa0801002, clock:0x0b82522b  2006/02/12 20:08:11
ofst[104]:err_code:0xa0801002, clock:0x0b825243  2006/02/12 20:08:35
ofst[108]:err_code:0xa0801002, clock:0x0b825255  2006/02/12 20:08:53
ofst[112]:err_code:0xa0801002, clock:0x0b89d5fe  2006/02/18 12:56:30
ofst[116]:err_code:0xa0232102, clock:0xffffffff
ofst[120]:err_code:0xa0232102, clock:0xffffffff
ofst[124]:err_code:0xa0232102, clock:0xffffffff
ofst[  0]:err_code:0xa0232102, clock:0xffffffff

>$ version
version
v1.3.3_k1

>$ bringup
bringup
[SSM] state: 0000 -> 0101
Bringup Mode #0 (0xFF)
[SSM] ssmCb_OnStartingBePowOn() called.
[SSM] First Boot.
[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 -> 0303
[SSM] PowSeq Fail : Detected !
[SSM] state: 0303 -> 0700
[POWSEQ] AV Backend Letup
[SSM] Shutdown mode : syspm_stat=00000000/00000000
[ERROR]: 0xa0232102
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)

lasterrlog
Last Error Code:0xa0232102, Time:0xffffffff

Yes, while the console is on and past boot is a typically when the tokin error first manifests. If you were just getting 1002 I would suspect Tokins, but a 2102 is not one I saw during my tests, which makes me think its voltage related. Maybe MOSFET or driver. Double check voltages to RSX, before replacing tokins. I noted the tokin progression like this...

• Random YLOD or Only in game YLOD = 80 1002 with timestamp.
  
• 2-10s YLOD = 80 1002 with timestamp.
• 1-2s YLOD = 10 to 80 1002 without timestamp.
• Instant, <1s YLOD = 09 3004

An oscilloscope would tell you if the tokins are bad. However, 23 is higher than the 10 state I had seen with a 1002 before. So if the 2102 were to happen like the 3004 did for me, at the 09 to 10 threshold during the power sequence, then I would have expected to see it in my testing somewhere between 2-10s YLODs. That's why I suspect a voltage issue. However, it could still just be the tokins. My tests were on a COK-001 and your board is newer with different parts, perhaps they trigger 2102...IDK. Also, my testing methodology jumped around a bit and the capacitance changes were not very gradual. It's possable there are other error states I did not capture. Wish you had an O-scope.

 

[TimeWalker75a]

An oscilloscope would tell you if the tokins are bad. However, 23 is higher than the 10 state I had seen with a 1002 before. So if the 2102 were to happen like the 3004 did for me, at the 09 to 10 threshold during the power sequence, then I would have expected to see it in my testing somewhere between 2-10s YLODs. That's why I suspect a voltage issue. However, it could still just be the tokins. My tests were on a COK-001 and your board is newer with different parts, perhaps they trigger 2102...IDK. Also, my testing methodology jumped around a bit and the capacitance changes were not very gradual. It's possable there are other error states I did not capture. Wish you had an O-scope.

Upon opening the console and removing the upper RF shield originally, I could see halo like white markings around each of the B side Token caps, which seemed odd. There's nothing like that on the chip side however.

It doesn't help that there's no schematic for DIA boards, but at least some of the components and general circuits around them check out, more on the SEM-001 side than the COK side it seems. Although the test points are a wild guessing game... that I'm not sure I will have the knowledge to figure out.

Always wanted an excuse to get a digital scope, especially now that they have come down in price (and size) severely, for measuring at mid-high frequencies. Could never justify the price nor the size of the traditional analogue scope.. so maybe this is the time I finally pull the plunge.

I'm guessing it would not be possible to identify the exact cap that could've gone bad due to the circuitry nature of each 4 cap array? But would just heading at the Token +/- rails highlight bad waveform?

 

[RIP-Felix]

Upon opening the console and removing the upper RF shield originally, I could see halo like white markings around each of the B side Token caps, which seemed odd.

Sounds like flux residue, meaning they might have been replaced before. But why? Did you notice any refurbishment stickers? Was it a sealed console?

Always wanted an excuse to get a digital scope, especially now that they have come down in price (and size) severely, for measuring at mid-high frequencies. Could never justify the price nor the size of the traditional analogue scope.. so maybe this is the time I finally pull the plunge.

I'm guessing it would not be possible to identify the exact cap that could've gone bad due to the circuitry nature of each 4 cap array? But would just heading at the Token +/- rails highlight bad waveform?

I can't recommend the RIGOL DS1054z highly enough. If you do a lot of electronics work get it and don't look back. You're right, it won't tell you which of the 4 tokins are bad. Even if it did you want to replace all 4 if you have to replace one anyway. Yes, probing the GND/+ rails gives a waveform that can clearly be seen as bad. There is a threshold where you still get 80 1002 errors, but it's not clearly bad on the scope. If it's bad enough to cause a 2-10s YLOD however, it'll definitely show the bad waveform. You can begin reading about it here...

I've got wonderful bad news! The CECHA01 I reballed last night is crashing during stress testing with GT6! I'll hold off on replacing the caps for a day or so to see if anyone (@RIP-Felix) comes up with any kind of relevant non-destructive (for the board, not the caps...) testing that they want to see, but I'm afraid I'm not willing to attempt to remove them intact on this one. The board has already been through 2 rework cycles, and it will take 4 more to remove them all. Combine that risk with the fact that I recently popcorned a warranty sealed system so I suspect uneven heat on my bottom plates that I may need to investigate soon, I'm not willing to risk this one when it just needs a simple fix.

Anyway, it was what is now the standard 3 second YLOD A0403034 with the normal amount of noise and fixed by a reball, however, the GPU caps had a very clear sawtooth waveform visible prior to rework.

Here's CPU idle at system menu, looking totally normal:

GPU idle at system menu, showing a very clear sawtooth wave, but notice when comparing it to the "bad" image in my signature, it doesn't have any "stuttering" to it and the amplitude is MUCH smaller. This image is pretty much identical to what I observed prior to rework:

CPU playing GT6, showing a very clear sine wave just like the bad image from my signature:

GPU playing GT6, the sawtooth is beginning to gain the "stutter" from the "bad" image:

And, more importantly, since most of you don't have oscilloscopes, the error log is now flooded with A0801001 and A0801002. The interesting thing about that, though, is that I only crashed it twice.... but it filled the error log with those two codes at all different times.

Anyway, this kind of confirms to me that capacitance and noise aren't really in play at all.... you're looking for that underlying waveform to swap over to looking like the images in my signature, and the amplitude of the sine or sawtooth wave is what really indicates the health of the caps, noise be damned. And we have confirmation that 1001 and 1002 error codes can come up from verified bad caps.

I'm now on board for switching out any caps that show a sawtooth or sine wave of ANY amplitude, or that give any 1001 or 1002 error codes. Let me be clear, though, for those that are reading this thread and don't have the means to perform any of this testing: your odds are still super, super low (4 in roughly 150 here now). Please, for the love of god, get the USB serial adapter that's like $5 and check the syscon thread before you start destroying things.

edit: yes, the Vpp doesn't match my spreadsheet. I'm still being sloppy and only do one freeze frame when filling out the sheet, so it can vary by a good bit depending on the spikes I catch.

edit 2: one other interesting thing of note - this board made my testing power supply whine like crazy. It has never done that before.

Then skip through the pages looking for my posts with the subheading PS3#7 - Update.