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

[lugh22]

Hello everyone,
Some time ago I posted the logs from an A01 that indicated bad tokins, I replaced the RSX caps and now the console boots without a problem, but now it started YLODing again, here are the new logs

Spoiler

Error Log
01: A0901001 Sun Jan 22 00:11:40 2006
02: A0901001 Sat Jan 21 23:55:59 2006
03: A0901001 Sat Jan 21 23:06:05 2006
04: A0801001 Fri Jan 20 20:55:44 2006
05: A0801001 Fri Jan 20 20:38:31 2006
06: A0901001 Fri Jan 20 20:27:45 2006
07: A0901001 Fri Jan 20 17:21:17 2006
08: A0801001 Fri Jan 20 17:19:20 2006
09: A0801001 Fri Jan 20 17:19:12 2006
10: A0901001 Fri Jan 20 17:12:38 2006
11: A0801001 Fri Jan 20 17:07:31 2006
12: A0801001 Fri Jan 20 17:06:51 2006
13: A0801001 Fri Jan 20 17:06:46 2006
14: A0801001 Fri Jan 20 17:06:13 2006
15: A0801001 Fri Jan 20 17:06:08 2006
16: A0901001 Fri Jan 20 17:04:35 2006
17: A0801001 Fri Jan 20 17:03:33 2006
18: A0801001 Fri Jan 20 17:03:27 2006
19: A0801001 Fri Jan 20 17:02:24 2006
20: A0801001 Fri Jan 20 17:01:47 2006
21: A0801001 Fri Jan 20 17:01:35 2006
22: A0901001 Fri Jan 20 01:25:51 2006
23: A0801001 Fri Jan 20 01:02:53 2006
24: A0801001 Fri Jan 20 00:59:01 2006
25: A0802022 Fri Jan 20 00:58:59 2006
26: A0802022 Thu Jan 19 23:12:33 2006
27: A0802022 Thu Jan 19 23:11:44 2006
28: A0802022 Thu Jan 19 23:11:21 2006
29: A0801001 Thu Jan 19 22:58:46 2006
30: A0801001 Thu Jan 19 22:58:05 2006
31: A0801001 Thu Jan 19 22:57:16 2006
32: FFFFFFFF Thu Jan 19 22:56:35 2006

Also, every time when I turn it off the PS3 beeps and blinking red light.
The 1001 codes are bad CELL tokins?
And about the 2022, the pdf with the codes says DVE Error, but I don't know what DVE means.
Before replacing the caps PS2 games failed to boot, after replacing still the same, so more problems to solve with this console.

 

[RIP-Felix]

The console is a CECHA01. How would I go about clearing the log, is that like just deleting the .txt file generated and running a new read or is it something more in depth?

I have another A01 that I beleive is YLOD that i'm gonna try frankensteing. I saw you mentioned in the thread about leaving the IHS on, just gonna have to go alittle passed 225 on my top heat to get it down, but it's worth the shot!

Reflow profiles typically ramp 1-1.5C/s and flow LF at 245-250C for a maximum of 40s dwell. Personally I think that's a bit high, I'd rather set LF at 235 max. But the Thermocouple needs to be accurate and the dwell time sufficient to be sure all the balls flow.

I'm curious what your steps are with that controller. (Eg, R1, L1, D1 R2, L2, D2, etc). I'm interested in how the reflow profile looks following those staircase step increases with dwell times. As opposed to a process controller able to follow a more accurate profile.

What I'm planning is similar to this.

I imagine dialing in the optimum reflow profile is difficult and unique for every board depending on it's construction. And the PS3 sinks heat like crazy, so I would think the dwell times had to be increased compared to a 360, but IDK...never worked on a 360.

To clear the SYSCON use the command clearerrlog. If you need details please reference my SYSCON tutorial here. It has everything you need to know.

 

[Shawn Shakir]

@RIP-Felix

I believe with these achi machines, you can kinda go crazy and add different stuff to it, as I've seen some with being able to use the controller software, but mine is pretty old and crusty, but it still gets the job done!

I use one profile for both but stop at different steps depending on what my thermocouples read, as you've already mentioned. I use about three of them around the chip just to be safe. Bottom heating is also key, preheat these bad boys as long as possible so you don't get any flex or popcorning going on.

My profile is pretty good, I use to pull pads back in the day but the last few years I haven't had any pads pulled or any of that, just gotta make sure I don't go too high in temps and break chips is all.

Honestly its these chips that are a pain. I suck terribly at reballing chips, i've only done like 2 360 CPU's successfully. Balls are small, i get annoyed, my hand then shakes, recipe for disater! It's also hard cause these 90nm RSX i'm guessing are the same as Non-hdmi 360 gpu's, they gonna work anywhere between one day - a year and then crap out again.

I wasn't sure if reflowing the 40nm with and IHS on would work, but might just read errors from the other A01 console I have and if it's RSX related, try reflowing it on that.

I also use to use a T8280 and an Aoyue 968 back in the day and did quite a bit of reflows and GPU replacements, no issue!

 

[RIP-Felix]

@RIP-FelixI also use to use a T8280 and an Aoyue 968 back in the day and did quite a bit of reflows and GPU replacements, no issue!

That's my ghetto setup currently. It works, but leaves alot to be desired. I was planning to hack the T8280 as the bottom heater, since it's large enough to preheat the PS3. And use an IR6500 for the top with that PC410 (cheap Altech p900 clone). I'm hoping that'll make things faster and easier to controll over hot iar with a 40mm nozel I'm currently using. It's too difficult to replicate a profile using it and always takes too long to heat up to reflow temps (oxidizing the balls more than is optimal. Reduces reliability). I like that I can hook it up to the PC and record the profile.

Have you tried that? How difficult is it to install and use the PC software. Do you know if it works with the clones or only on genuine p900s?

 

[sandungas]

Or to make it short and simple I'll just have to install python and connect ps3 superslim to ttl Hart converter to PC and authenticate with syscon reader gui then run both the command you requested and the syscon dump script right.

Yes, but is better if you get used to run the .py files (scripts) manually, you just need to open a terminal in the same directory where is located the .py file and run it just by typing its name (with the "COMx" and "SW" at the end)
Btw, the app you was using only displays 20 error codes in both your consoles, but the errorlog can store up to 32... this probably means both your consoles have a few more errors... 21... 22... and so on

Well there's few question for you will dumping whole syscon also dumps your requested id too and does clearing errorlog gonna make console both for once too.Any way storage memory contents can be read and flashed via syscon just curious.I do it today hope it works.Anything science right.

Yes, if you open the file in a hexeditor it starts like this:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  C0 43 6F 6B 50 31 30 00 00 51 60 40 FF FF FF FF  ÀCokP10..Q`@ÿÿÿÿ
00000010  01 4E 00 FF FF 1A 03 BC 2C FF FF FF FF FF FF FF  .N.ÿÿ..¼,ÿÿÿÿÿÿÿ
00000020  00 02 00 00 03 C8 78 FF FF FF FF 00 FF FF FF FF  .....Èxÿÿÿÿ.ÿÿÿÿ
00000030  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000040  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

As you can see the name "Cok..." is located at beginning

Clearing the errorlog doesnt helps the console to boot, or in other words... the errors doesnt prevents the console to boot
Actually, if the console have a problem and you clear the errorlog syscon is going to add a new error in the next boot, and so on and so on... everytime you reboot there is a new error (related with the actual problem that prevents the PS3 to boot)
The point of clearing the errorlog is because at the next reboot of the PS3 the list is going to contain only 1 error (or 2 or 3 as much, incase are related with each others)
But another way to achieve that is by rebooting the PS3 several times... to allow syscon to cummulate a bunch of errors that are going to have a similar timestamp, this way you know you need to focus your attention in them

 

[RIP-Felix]

Hello everyone,
Some time ago I posted the logs from an A01 that indicated bad tokins, I replaced the RSX caps and now the console boots without a problem, but now it started YLODing again, here are the new logs

Spoiler

Error Log
01: A0901001 Sun Jan 22 00:11:40 2006
02: A0901001 Sat Jan 21 23:55:59 2006
03: A0901001 Sat Jan 21 23:06:05 2006
04: A0801001 Fri Jan 20 20:55:44 2006
05: A0801001 Fri Jan 20 20:38:31 2006
06: A0901001 Fri Jan 20 20:27:45 2006
07: A0901001 Fri Jan 20 17:21:17 2006
08: A0801001 Fri Jan 20 17:19:20 2006
09: A0801001 Fri Jan 20 17:19:12 2006
10: A0901001 Fri Jan 20 17:12:38 2006
11: A0801001 Fri Jan 20 17:07:31 2006
12: A0801001 Fri Jan 20 17:06:51 2006
13: A0801001 Fri Jan 20 17:06:46 2006
14: A0801001 Fri Jan 20 17:06:13 2006
15: A0801001 Fri Jan 20 17:06:08 2006
16: A0901001 Fri Jan 20 17:04:35 2006
17: A0801001 Fri Jan 20 17:03:33 2006
18: A0801001 Fri Jan 20 17:03:27 2006
19: A0801001 Fri Jan 20 17:02:24 2006
20: A0801001 Fri Jan 20 17:01:47 2006
21: A0801001 Fri Jan 20 17:01:35 2006
22: A0901001 Fri Jan 20 01:25:51 2006
23: A0801001 Fri Jan 20 01:02:53 2006
24: A0801001 Fri Jan 20 00:59:01 2006
25: A0802022 Fri Jan 20 00:58:59 2006
26: A0802022 Thu Jan 19 23:12:33 2006
27: A0802022 Thu Jan 19 23:11:44 2006
28: A0802022 Thu Jan 19 23:11:21 2006
29: A0801001 Thu Jan 19 22:58:46 2006
30: A0801001 Thu Jan 19 22:58:05 2006
31: A0801001 Thu Jan 19 22:57:16 2006
32: FFFFFFFF Thu Jan 19 22:56:35 2006

Also, every time when I turn it off the PS3 beeps and blinking red light.
The 1001 codes are bad CELL tokins?
And about the 2022, the pdf with the codes says DVE Error, but I don't know what DVE means.
Before replacing the caps PS2 games failed to boot, after replacing still the same, so more problems to solve with this console.

Yes, you have a 1001 error at step number 90. That's the power off state. It's erring out while powering off.

As for why, that's hard to know. We've had lots of 1001's but no difinitive single cause. It's associated with lots of things. However, I think it would be prudent to replace the CPU side tokins and see if that works.

Can you post pics of the tantalum install? Also, which caps did you use?

 

[Fallen777]

Yes, but is better if you get used to run the .py files (scripts) manually, you just need to open a terminal in the same directory where is located the .py file and run it just by typing its name (with the "COMx" and "SW" at the end)
Btw, the app you was using only displays 20 error codes in both your consoles, but the errorlog can store up to 32... this probably means both your consoles have a few more errors... 21... 22... and so on

Yes, if you open the file in a hexeditor it starts like this:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  C0 43 6F 6B 50 31 30 00 00 51 60 40 FF FF FF FF  ÀCokP10..Q`@ÿÿÿÿ
00000010  01 4E 00 FF FF 1A 03 BC 2C FF FF FF FF FF FF FF  .N.ÿÿ..¼,ÿÿÿÿÿÿÿ
00000020  00 02 00 00 03 C8 78 FF FF FF FF 00 FF FF FF FF  .....Èxÿÿÿÿ.ÿÿÿÿ
00000030  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000040  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

As you can see the name "Cok..." is located at beginning

Clearing the errorlog doesnt helps the console to boot, or in other words... the errors doesnt prevents the console to boot
Actually, if the console have a problem and you clear the errorlog syscon is going to add a new error in the next boot, and so on and so on... everytime you reboot there is a new error (related with the actual problem that prevents the PS3 to boot)
The point of clearing the errorlog is because at the next reboot of the PS3 the list is going to contain only 1 error (or 2 or 3 as much, incase are related with each others)
But another way to achieve that is by rebooting the PS3 several times... to allow syscon to cummulate a bunch of errors that are going to have a similar timestamp, this way you know you need to focus your attention in them

OK i got the platform ID for the PQX-001 EMMC version board. Attaching photo below:

Gonna go ahead and dump the whole syscon too

 

[vyktormvmpay25]

How you going to dump it "full"? is only a part of it over uart ,unless I dont know something? The full dump method is complex and I didnt achieve ,few ppl around world can do it.Isn't public atm.Tried something but didnt work for me.Full is kind of glitch and dangerous ,may brick unit if not careful

 

[sandungas]

OK i got the platform ID for the PQX-001 EMMC version board. Attaching photo below:View attachment 35236
Gonna go ahead and dump the whole syscon too

Thanks a lot, i added it to the Platform ID page

The sherwood syscon dumps made by the python script are 0x1400 bytes size, is small but there are hundreds of settings
If you are curious about something relativelly easy to identify... check at offset 0x250 is the Thermal Config
From that wiki page... (in theory) your motherboard PQX-001 should use the one that appears under page setion "CRC32: 8E7F2A49"
Starting with 33 3D 00 00 00 36 3E 00... etc...

If for some reason (not much probable) your motherboard PQX-001(eMMC) have a thermal config different than the one that appears in that wiki page advise me and share it to add it to the collection

 

[littlebalup]

Thanks a lot, i added it to the Platform ID page

The sherwood syscon dumps made by the python script are 0x1400 bytes size, is small but there are hundreds of settings
If you are curious about something relativelly easy to identify... check at offset 0x250 is the Thermal Config
From that wiki page... (in theory) your motherboard PQX-001 should use the one that appears under page setion "CRC32: 8E7F2A49"
Starting with 33 3D 00 00 00 36 3E 00... etc...

If for some reason (not much probable) your motherboard PQX-001(eMMC) have a thermal config different than the one that appears in that wiki page advise me and share it to add it to the collection

I missed a ton of info in that huge thread but what is the Hex platform ID column? Where does this hex value comes from?

 

[sandungas]

I missed a ton of info in that huge thread but what is the Hex platform ID column? Where does this hex value comes from?

Is inside the syscon firmware, the platform id (in text format) is just intended to be used as a output for humans, in readable format... but internally syscon converts it to hex

Note how the "CokJ13" and "CokJ20" (the 2 posible motherboards for PS3 models CECH-25xx) are sharing the same platform id in hex format
In the practise it means that syscon firmware considers the platform id "CokJ13" and "CokJ20" (in text format) are the same thing (both are platform id = 0x80 in hex format)

Same stuff with the DEB-001 motherboard (sharing the same hex value than DIA-002)
This syscon feature is what is refered as "hardcoded" in the table

 

[littlebalup]

Is inside the syscon firmware, the platform id (in text format) is just intended to be used as a output for humans, in readable format... but internally syscon converts it to hex

Note how the "CokJ13" and "CokJ20" (the 2 posible motherboards for PS3 models CECH-25xx) are sharing the same platform id in hex format
In the practise it means that syscon firmware considers the platform id "CokJ13" and "CokJ20" (in text format) are the same thing (both are platform id = 0x80 in hex format)

Same stuff with the DEB-001 motherboard (sharing the same hex value than DIA-002)
This syscon feature is what is refered as "hardcoded" in the table

Ok thanks.

One kind of mistery for me with the super slims is about the two different "versions" of CECH-40xxx.
The "v1" with product sub codes 0x0D (B/C NOR) and 0x0E (A eMMC).
The "v2" with product sub codes 0x0F (B/C NOR) and 0x10 (A eMMC).
However I never seen any IDPS from super slim dumps with 0x10 product sub code till now (that said I didn't seen a ton of super slim dump compared to the fat/slims).

Why did they made two set of product sub codes without rolling the model number? Mystery. We never seen that with the other retail models.
In contrary we already seen different models with the same product sub code: CECHCxx and CECHExx that are the exact same machines, 0x03 product sub code (I personnaly never seen 0x04 on a CECHExx contrarly of what is in this table).

I know for sure 0x0E is MPX-001 eMMC (CokM30) as it's one of mine. It looks like MSX-001 are "v1" too but I can't confirm.
The "v2" are suposely NPX-001 but it would be great to have firm confirmation too.

 

[sandungas]

Ok thanks.

One kind of mistery for me with the super slims is about the two different "versions" of CECH-40xxx.
The "v1" with product sub codes 0x0D (B/C NOR) and 0x0E (A eMMC).
The "v2" with product sub codes 0x0F (B/C NOR) and 0x10 (A eMMC).
However I never seen any IDPS from super slim dumps with 0x10 product sub code till now (that said I didn't seen a ton of super slim dump compared to the fat/slims).

Why did they made two set of product sub codes without rolling the model number? Mystery. We never seen that with the other retail models.
In contrary we already seen different models with the same product sub code: CECHCxx and CECHExx that are the exact same machines, 0x03 product sub code (I personnaly never seen 0x04 on a CECHExx contrarly of what is in this table).

I know for sure 0x0E is MPX-001 eMMC (CokM30) as it's one of mine. It looks like MSX-001 are "v1" too but I can't confirm.
The "v2" are suposely NPX-001 but it would be great to have firm confirmation too.

When you have some free time and the patience required to follow all our brainstormings you have to take a read at this talk starting from this post https://www.psx-place.com/threads/s...o-what-does-it-mean.26148/page-21#post-313106
I quoted you but i had to edit my post several times to rewrite stuff more accuratelly, fix typos, etc... so i guess you missed it
And this other talk is also related indirectly https://www.psx-place.com/threads/release-ps3-advanced-tools.34104/page-3#post-313112

Basically... when looking at the wiki table for "product sub code" for superslim PS3 models it seems this rules are applyed:
*Every "product sub code" can be assigned to a specific motherboard name
*Every motherboard name have 2 "platform id" (depends of the flash type)
*We have 8 "product sub code" (not counting the 0x8F and 0x90)... this makes a total of 16 "platform id"

Since i added a new column for the "platform id" in the "product sub code" table it means we need to duplicate the rows of the table for superslims, and it seems it needs to be made this way:

Try to apply the same rule in the previous superslims PS3 models (and keep an eye at the known platform id names from the other table) and you will realize is a bit more weird... because there is a unkown motherboard in between (the owner of platform id = CokN20 and CokN40)

This is why i mentioned this, in this post:
https://www.psx-place.com/threads/s...o-what-does-it-mean.26148/page-21#post-313478

One way or the other... the actual "product sub code" table is assigning the 8 product subcodes to 8 retail PS3 models, i guess thats not right (because one of them is the UNK-001 motherboard)... so we need to delete one of the "PS3 model" names and replace it by a question mark

As you can see in that talk @M4j0r agreed with that, we are not 100% sure but it seems we need to delete one of the "PS3 model" names from the "Product sub code" table
So... is super interesting you mentioned this, it seems we have a candidate

However I never seen any IDPS from super slim dumps with 0x10 product sub code till now (that said I didn't seen a ton of super slim dump compared to the fat/slims).

If you can confirm that "product sub code" = 0x0D, 0x0E, 0xF, 0x11, 0x12, 0x13, 0x14 was found used in the dumps you have (in other words, you are sure that was used in retail) then i guess the 0x10 is the easter egg

 

[littlebalup]

When you have some free time and the patience required to follow all our brainstormings you have to take a read at this talk starting from this post https://www.psx-place.com/threads/s...o-what-does-it-mean.26148/page-21#post-313106
I quoted you but i had to edit my post several times to rewrite stuff more accuratelly, fix typos, etc... so i guess you missed it
And this other talk is also related indirectly https://www.psx-place.com/threads/release-ps3-advanced-tools.34104/page-3#post-313112

Basically... when looking at the wiki table for "product sub code" for superslim PS3 models it seems this rules are applyed:
*Every "product sub code" can be assigned to a specific motherboard name
*Every motherboard name have 2 "platform id" (depends of the flash type)
*We have 8 "product sub code" (not counting the 0x8F and 0x90)... this makes a total of 16 "platform id"

Since i added a new column for the "platform id" in the "product sub code" table it means we need to duplicate the rows of the table for superslims, and it seems it needs to be made this way:

Try to apply the same rule in the previous superslims PS3 models (and keep an eye at the known platform id names from the other table) and you will realize is a bit more weird... because there is a unkown motherboard in between (the owner of platform id = CokN20 and CokN40)

This is why i mentioned this, in this post:
https://www.psx-place.com/threads/s...o-what-does-it-mean.26148/page-21#post-313478

As you can see in that talk @M4j0r agreed with that, we are not 100% sure but it seems we need to delete one of the "PS3 model" names from the "Product sub code" table
So... is super interesting you mentioned this, it seems we have a candidate

If you can confirm that "product sub code" = 0x0D, 0x0E, 0xF, 0x11, 0x12, 0x13, 0x14 was found used in the dumps you have (in other words, you are sure that was used in retail) then i guess the 0x10 is the easter egg

That's all i have in my table for the superslims

As you can see, no 0x10 . However, NPX-001 eMMC seems to exist : https://www.psdevwiki.com/ps3/File:PPX-001_eMMC_top_side.jpg
So, IDK...

 

[lugh22]

Yes, you have a 1001 error at step number 90. That's the power off state. It's erring out while powering off.

As for why, that's hard to know. We've had lots of 1001's but no difinitive single cause. It's associated with lots of things. However, I think it would be prudent to replace the CPU side tokins and see if that works.

Can you post pics of the tantalum install? Also, which caps did you use?

Here is the picture of the caps installed:

Spoiler

I re-solder them because one of the was loose, but still the same problem.
To give a little more info, the YLOD happens when starting a PS2 classic game, or after some time playing a PS3 game, checking the logs again and it's just 1001.

 

[sandungas]

That's all i have in my table for the superslims
View attachment 35237

As you can see, no 0x10 . However, NPX-001 eMMC seems to exist : https://www.psdevwiki.com/ps3/File:PPX-001_eMMC_top_side.jpg
So, IDK...

You can idenitify the motherboard name by crosschecking the product sub code and the flash type... and also eventually you can deduce the "platform id" (not yet, but after we complete the list of Platform ID)

Btw, if you click in the "edit" link at top-right corner of the table in the Product Sub Code page is going to take you to Template:Minimum Firmware Version
In it you can see there are some notes at bottom that are hidden in the "product subcode" page (there is even an small table, partial), is something temporal, eventually we need to join together both tables

Anyway, by now it seems the list is like this
product sub code = 0x0D ---> MSX-001
product sub code = 0x0E ---> MPX-001
product sub code = 0x0F ---> NPX-001
product sub code = 0x10 ---> Unknown motherboard, probably named NSX-001, and probably never used in retail production
product sub code = 0x11 ---> PQX-001
product sub code = 0x12 ---> PPX-001
product sub code = 0x13 ---> RTX-001
product sub code = 0x14 ---> REX-001

The first 3 of this list are a bit doubtful (because the way how the engineers was ordering them), but the last 4 are more straightforward

 

[RIP-Felix]

To give a little more info, the YLOD happens when starting a PS2 classic game, or after some time playing a PS3 game, checking the logs again and it's just 1001.

@Pacorretaco is of the opinion that 1001 errors happen "simply when there's a power cut." That it indicates nothing more than an unexpected shutdown.

...What's interesting about the 1001 is how finicky it is. @squeept was getting an error log full of 1001 and 1002's testing PS3#7 before I traded him for it. In shipping it took a lucky strike strait to the Tokin and all the 1001's disappeared for me. I only got 1002's. Thinking back on this now, he said he only crashed it twice under load. So all those codes occurred at different times. But I know from experiance with the oscilloscope, you have to turn the console on/off a bunch of times to get scope images. @Pacorretaco noted that 1001's can occur from improperly shutting power down. @marciolsf got one by accidentally bridging 2 pins on a clock generator IC and shorting out a 0.1uF MLCC! Interestily it generated a 2120 at the same time. Just flipping the switch off without a graceful shutdown can cause them. It's common to see them in GLOD consoles that get stuck and won't shut off any other way. You have to flip the rocker, which is enough to generate them...

They often occur in testing when the console is turned on/off a lot, instead of waiting for a graceful shutdown every time. If console is idle and you flip PWR off, instead of a graceful shutdown, it'll generate 80 1001 (PWR on state). It can happen in a PWR off state (90 1001), like a YLOD occurring during shutdown. There doesn't appear to be any single cause for what would cause an unexpected shutdown.

I've had 1002 errors that caused a YLOD at boot (80 1002), but there were no 1001's. So my Hypothesis is that 1001's only occur if the console makes it past a successful startup. I'm not sure that's always the case, though. It seems like people have seen them on instant YLOD's. So we need to confirm or refute that hypothesis. So far, I like the idea that 1001's only occur on unexpected shutdowns, and if the console doesn't boot to begin with that's not an unexpected shutdown. It's a boot failure, with a different set of errors.

***EDIT: @DeadEnd did have a 20 1001 in this post, which is early in the boot process. Also, @marciolsf had 40 1001 in this post. So these errors refute this hypothesis. On the other hand, both of those cases were associated with other errors indicating CPU PWR issues, possibly BGA defects or VRM related.***

PS2 Classics are emulated on PS3, which I assume is a CPU intensive process. I'm guessing that the RSX is not used that much. So if the CPU filter (tokins) isn't adequate, the demand of emulated games could be enough to cause a YLOD. Since the console is on, that should generate an 80 1001 (PWR ON state). I'm not sure why it would hang on shutdown.

@lugh22 can you run the SYSCON script in a CMD terminal and keep it open while you attempt to recreate the YLOD on shutdown? I want to see what the log records during the shutdown process. I'd like to get a feel for what point the error happen, which might help us figure out what could be causing it to hang.

 

[marciolsf]

Also, @marciolsf had 40 1001 in this post.

Lol, I had to look up my own post, because I didn't remember that. I do have some more context, though -- I only got 40 1001 when I caused a short and burned a fuse (specifically PS6001). It went away when I fixed the fuse. there's a chance the error was more related to the short than the fuse.

It's also interesting to note that some time later when I was doing a series of experiments where I removed all the tokins, then added them back one at a time and measured with my 'scope, I'm fairly certain I never got a 1001… Only 3034's. I did a great many other experiments, and probably the only other time I got another 1001 is when i shorted one of the regulators and killed a cap. Id have to find the post to see which errors i actually got, but they all went away when i fixed the cap (and back to 3034 it was).

 

[lugh22]

@lugh22 can you run the SYSCON script in a CMD terminal and keep it open while you attempt to recreate the YLOD on shutdown? I want to see what the log records during the shutdown process. I'd like to get a feel for what point the error happen, which might help us figure out what could be causing it to hang

Sure, I just need to get a USB to TTL adapter, I have been using the PS3 Advanced Tools to get the logs since the PS3 can boot.
Anyone was able to use a raspberry pi to connect to syscon?
I already have a pi 4 and the GPIO have 2 UART's and runs at 3.3v, so I don't need to buy the adapter.
I did try myself but never worked, when using the AUTH command I get a response but an error occurs when decoding the message, probably I am missing some configuration since the message is different everytime I run the command.

 

[RIP-Felix]

Well, I know the script requires some dependencies. Pyserial and pycryptodome. I'm not sure if you can get them working with Rpi like you can in python on windows.

The adapter is cheap. So why not?