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

@RIP-Felix I still have the customer details, I can ask him if he was doing anything with custom firmware (he's already been refunded, so there's no need to be dodgy about details). Sounds like the next step is the RAM regardless, though. Heat / pressure test them?

Would a dodgy shorting CELL RAM chip reflect a dirty power signal through to both the RSX and CELL signals? Maybe find the power for those, probe each one, and compare it to a known good board? 4 chips, 4 channels on the RIGOL....
 
I'll look into it, but I'm not in a big hurry. I'm working on another project I want to finish this summer, so that's the priority. But I'll circle back to this at some point. It's a super low use board and would be great if I could get it working.

I have never encountered XDR fail errors with insufficient VDDC filtering and your array of 16x B case 330uF caps should be sufficient (5280uF). But I can try adding tantalizer to see if that helps, JIC. I mean, you are forcing the current through just 2 conductors, but they should be sufficiently large.
 
#8 (I think)

s-l1600.jpg
 
Hi there! I would like to ask help interpreting/diagnosing my PS3's error codes.
It's a SEM-001 Board (CECHGxx Model, PS3 Phat) and I already have access to the internal command mode. Its main problem is that it seems to be experiencing YLOD after more than 5 years of not being used and being stored in a corner somewhere. Here's the following errlog, bringup, and becount logs.

ofst[ 24]:err_code:0xffffffff, clock:0x2a55424c 2022/07/04 06:16:44
ofst[ 28]:err_code:0xa0101002, clock:0x2a55426c 2022/07/04 06:17:16
ofst[ 32]:err_code:0xa0101002, clock:0x2a55427d 2022/07/04 06:17:33
ofst[ 36]:err_code:0xa0231002, clock:0x2a5542a7 2022/07/04 06:18:15
ofst[ 40]:err_code:0xa0101002, clock:0x2a5542ba 2022/07/04 06:18:34
ofst[ 44]:err_code:0xa0231002, clock:0x2a67d4d8 2022/07/18 08:22:48
ofst[ 48]:err_code:0xa0101002, clock:0x2a67d4e4 2022/07/18 08:23:00
ofst[ 52]:err_code:0xa0101002, clock:0x2a67d4ed 2022/07/18 08:23:09
ofst[ 56]:err_code:0xa0231002, clock:0x2a67d4f3 2022/07/18 08:23:15
ofst[ 60]:err_code:0xa0101002, clock:0x2a67d51f 2022/07/18 08:23:59
ofst[ 64]:err_code:0xa0101002, clock:0x2a67d527 2022/07/18 08:24:07
ofst[ 68]:err_code:0xa0101002, clock:0x2a67d52d 2022/07/18 08:24:13
ofst[ 72]:err_code:0xa0101002, clock:0x2a67d5bc 2022/07/18 08:26:36
ofst[ 76]:err_code:0xa0101002, clock:0x2a67d5e2 2022/07/18 08:27:14
ofst[ 80]:err_code:0xa0101002, clock:0x2a67d5ed 2022/07/18 08:27:25
ofst[ 84]:err_code:0xa0231002, clock:0x2a67d657 2022/07/18 08:29:11
ofst[ 88]:err_code:0xa0101002, clock:0x2a67d65b 2022/07/18 08:29:15
ofst[ 92]:err_code:0xa0101002, clock:0x2a67d661 2022/07/18 08:29:21
ofst[ 96]:err_code:0xa0101002, clock:0x2a67d664 2022/07/18 08:29:24
ofst[100]:err_code:0xa0101002, clock:0x2a67d78b 2022/07/18 08:34:19
ofst[104]:err_code:0xa0101002, clock:0x2a67d792 2022/07/18 08:34:26
ofst[108]:err_code:0xa0101002, clock:0x2a67d796 2022/07/18 08:34:30
ofst[112]:err_code:0xa0101002, clock:0x2a67d7a0 2022/07/18 08:34:40
ofst[116]:err_code:0xa0101002, clock:0x2a75232a 2022/07/28 10:36:26
ofst[120]:err_code:0xa0101002, clock:0x2a753def 2022/07/28 12:30:39
ofst[124]:err_code:0xa0101002, clock:0x2a753e02 2022/07/28 12:30:58
ofst[ 0]:err_code:0xa0101002, clock:0x2a753e0d 2022/07/28 12:31:09
ofst[ 4]:err_code:0xa0101002, clock:0x2a753e15 2022/07/28 12:31:17
ofst[ 8]:err_code:0xa0101002, clock:0x2a753e76 2022/07/28 12:32:54
ofst[ 12]:err_code:0xa0101002, clock:0x2a753e7f 2022/07/28 12:33:03
ofst[ 16]:err_code:0xa0101002, clock:0x2a753e84 2022/07/28 12:33:08
ofst[ 20]:err_code:0xa0231002, clock:0x2a753e88 2022/07/28 12:33:12

>$ 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] fatalreq delayed.
[ERROR]: 0xa0101002
[SSM] state: 0101 -> 0201
[POWSEQ] AV Backend Setup
[SSM] *** Power Fail RS ***
[SSM] state: 0201 -> 0700
[POWSEQ] AV Backend Letup
[SSM] Shutdown mode : syspm_stat=00000000/00000000
>$
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)

[mullion]$

Bringup : 850 times
Shutdown: 749 times
Power-on: 55day 12hour 56min 20sec
[mullion]$

I'm not sure if this is necessary but after the initial errlogs there are extra error codes with no dates. I assume it's probably normal since I have the board wired up right now to my PC.

*same as above error logs*
ofst[ 24]:err_code:0xa0101002, clock:0xffffffff
ofst[ 28]:err_code:0xa0101002, clock:0xffffffff
ofst[ 32]:err_code:0xa0101002, clock:0xffffffff

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

I already tried looking at the wiki on what a 1002 error could mean and besides pointing at 3 components being involved, it states that it could be the NEC capacitors. Though seeing everything I've read about YLOD diagnosing and RIP-Felix's READTHIS, I want to make sure if everything actually points towards the capacitor or if it could be something else especially besides the A0101002 error I was also getting a A0231002 which I have no idea what it means to have that kind of difference in the power step.

Also possibly unrelated note, my dad previously opened this console around probably 2022/07/18 which might explain the massive amount of recent error logs and before I decided to finally diagnose the syscon the power button doesn't seem to work anymore. Is there any fix for this? I can still touch the power button on the board itself and it works perfectly, I assume it's probably just on the touching part on the case itself.

I apologize if I missed stating anything else, I hope I provided enough information to be helpful!
 
...After saving the log I cleared it and used the bringup command to start the console. It compleated Power On Sequencing and began the FW sequence that starts the Boot Loader. There were no errors that triggered a YLOD or that would indicate there's an issue with HW. The only one that I found confusing was the "[ERROR]: 0xb0002002 (FATAL) XDR Link not initilized."

It then proceeded to Dump the ITC, PTC, MIC, and XIO. I do not know how to make sense of the specific information they might contain. Perhaps someone more familiar with the bootloader can shed some light on whether or not this is useful.
I been updating this page in the last couple of weeks btw, click in the arrow at top for the "description" column to reorganize the columns and have all the pads with the description "Connected to XDR..." together
Or click in the "internal" arrow to see how much starts with the codenames Y0 or Y1
https://www.psdevwiki.com/ps3/Template:CELL_pad_layout_90nm

Im sure the dump of the MIC and XIO is giving info related with the problem because are the blocks directly related with the XDR DRAM bus, it can be seen in this photo, actually i think the codename XIO is a comptraction of XDRIO (and have some thing in common with the FlexIO because both are patented by rambus company), it can be seen in this photo
https://www.psdevwiki.com/ps3/File:Cell-90nm-die.png

Basically... in every "pulse" of the XIO bus it can send 8 bytes (64 bits), but is made by pairs of wires, so there are 128 data lines in between CELL and the XDR chips (32 data lines each chip)
Additionally, every pair of XDR chips (Y0 is the first pair, and Y1 is the second pair) have 12 lines for commands + 3 or 4 more for command control

But... the most importants are the lines mentioned by @M4j0r responsibles for the clocks, codenamed CTM (clock to master) and CFM (clock from master), this is a bit tricky and im not sure if i understand it completly, but the point is... the component ICS9218AGLFT (IC5002) sends the clocks to CELL (at this point the signals is named clock to master)... then CELL sends the clocks to the XDR chips (at this point the signals is named clock from master)

You know... CELL is the master... the clocks are generated by ICS9218AGLFT but needs to pass throught CELL (i guess is some kind of supervision this way CELL knows the cloks are fine before sending them to the XDR chips)

In other words the clocks are traced this way (P=positive, N=negative)
ICS9218AGLFT --->CTMP (Y0)--->CELL pad J1
ICS9218AGLFT --->CTMN (Y0)--->CELL pad J2
ICS9218AGLFT --->CTMP (Y1)--->CELL pad AP1
ICS9218AGLFT --->CTMN (Y1)--->CELL pad AP2

CELL pad K1 ---->CFMP (Y0)---> XDR
CELL pad K2 ---->CFMN (Y0)---> XDR
CELL pad AR1 --->CFMP (Y1)---> XDR
CELL pad AR2 --->CFMN (Y1)---> XDR

If we consider the CELL pads are fine, and the problem is related with this clock lines is either a matter to check this lines with the osciloscope before CELL and after CELL

*There are also around 6 CELL pads named "reference resistors" dedicated to the XDR bus (a couple of them have a cap)... you will find them in the service manuals in 2 groups "Y0" and "Y1"

Beyond that the only other interesting this I learned from the SYSCON "Boot Loader SE Version 0.9.5 (Build ID: 1634,16289, Build Data: 2006-09-21_19:11:09)." According to the PS3 Dev Wiki, this version (0.9.5) is not on CEX (Retail) models and this particular Build ID (1634) isn't listed there. But @DeadEnd did find it here.
@M4j0r we should add it to the list ?, i added others before, but everytime i do im not sure i have doubts about whats the info displayed by syscon, is always the version of lv0ldr ?


I attempted a SB UART, but couldn't get anything to output. I think it's not getting far enough into the bootloader for the SB to output anything, but I'm not %100 sure I did it correctly. This was the first time I've attempted the SB UART.

The only thing I can think of is the customer downgraded the console to a system firmware that is incompatible with the 65nm RSX. Anything below 2.15 - 2.30 (Not sure exactly) will cause a GLOD. @vyktormvmpay25 discovered this in a MB he Frankied for @mathieulh. He was able to get into Safe mode, but couldn't see anything.

I tried to get into safe mode, but it doesn't trigger. The procedure just turns the console off every time. No 1-beep, 2-beep, etc. However, safe mode isn't present on early system firmware, so if the customer did downgrade that could be normal. I'm not 100% sure that's what's going on here, but I have suspicions.

Can anyone confirm that the "Boot Loader Version" is updated when "System Firmware" is? Would the bootloder being at 0.9.5 confirm that they must have downgraded the FW below 2.30?

I've ordered a FlashcatUSB xPort and a TSOP-48 NAND Programmer.

@vyktormvmpay25 @sandungas @M4j0r you guy's would have a better idea of how I should proceed. I think dumping the NAND and then attempting to upgrade to 3.55 would be the first place to start, but if you have any other suggestion I'm all ears.
The bootloader version is not uploaded with a standard firmware installation, dont worry about that or other software or flash problems, to me it looks the problem is in the RAM
In the worst case scenario (you know that desperate method that sometimes works) you are going to need to start replacing all the related components... starting with the IC5002 and his surrounding components, together with the "Y0 and Y1 reference resistors" i mentioned... and continuing with the RAM chips themselfs

There is a pad layout in this page btw, the image at right, it could help
https://www.psdevwiki.com/ps3/X5116AC-3C-E
 
Last edited:
@M4j0r we should add it to the list ?, i added others before, but everytime i do im not sure i have doubts about whats the info displayed by syscon, is always the version of lv0ldr ?
lv0ldr will output it's version over the Syscon UART. lv0 prints its version over the SB UART. Sony calls lv0ldr and lv0 both bootloader, but lv0ldr version 0.9.5 is already on the list https://www.psdevwiki.com/ps3/Talk:Flash:bootldr .
 
Hello to the community, I'm pretty new to repairing PS3s and decide to give it a shot to repair my old YLOD CECHC04 with COK-002 board. I ran SYSCON and got the following error codes:

00000000 A0801001 0B488681
00000000 A0801200 0B488682
00000000 A0801002 0B488684
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF

After reflowing the RSX it has no longer YLOD and turns on propery so please ignore the first 3 lines about overheating since I powered it on for a few secs with no cooler attached (haven't assembled again to test display output though). So could it be just bad BGA joints that a good reflow or even reballing can fix or the RSX is completely gone and will have YLOD in a few months even with reballing? Also if I understood correctly I could install a 40nm RSX without an orbis mod and modifying the board at all and just by modding it through syscon? Thanks!
 
Hi there! I would like to ask help interpreting/diagnosing my PS3's error codes.
It's a SEM-001 Board (CECHGxx Model, PS3 Phat) and I already have access to the internal command mode. Its main problem is that it seems to be experiencing YLOD after more than 5 years of not being used and being stored in a corner somewhere. Here's the following errlog, bringup, and becount logs.

ofst[ 24]:err_code:0xffffffff, clock:0x2a55424c 2022/07/04 06:16:44
ofst[ 28]:err_code:0xa0101002, clock:0x2a55426c 2022/07/04 06:17:16
ofst[ 32]:err_code:0xa0101002, clock:0x2a55427d 2022/07/04 06:17:33
ofst[ 36]:err_code:0xa0231002, clock:0x2a5542a7 2022/07/04 06:18:15
ofst[ 40]:err_code:0xa0101002, clock:0x2a5542ba 2022/07/04 06:18:34
ofst[ 44]:err_code:0xa0231002, clock:0x2a67d4d8 2022/07/18 08:22:48
ofst[ 48]:err_code:0xa0101002, clock:0x2a67d4e4 2022/07/18 08:23:00
ofst[ 52]:err_code:0xa0101002, clock:0x2a67d4ed 2022/07/18 08:23:09
ofst[ 56]:err_code:0xa0231002, clock:0x2a67d4f3 2022/07/18 08:23:15
ofst[ 60]:err_code:0xa0101002, clock:0x2a67d51f 2022/07/18 08:23:59
ofst[ 64]:err_code:0xa0101002, clock:0x2a67d527 2022/07/18 08:24:07
ofst[ 68]:err_code:0xa0101002, clock:0x2a67d52d 2022/07/18 08:24:13
ofst[ 72]:err_code:0xa0101002, clock:0x2a67d5bc 2022/07/18 08:26:36
ofst[ 76]:err_code:0xa0101002, clock:0x2a67d5e2 2022/07/18 08:27:14
ofst[ 80]:err_code:0xa0101002, clock:0x2a67d5ed 2022/07/18 08:27:25
ofst[ 84]:err_code:0xa0231002, clock:0x2a67d657 2022/07/18 08:29:11
ofst[ 88]:err_code:0xa0101002, clock:0x2a67d65b 2022/07/18 08:29:15
ofst[ 92]:err_code:0xa0101002, clock:0x2a67d661 2022/07/18 08:29:21
ofst[ 96]:err_code:0xa0101002, clock:0x2a67d664 2022/07/18 08:29:24
ofst[100]:err_code:0xa0101002, clock:0x2a67d78b 2022/07/18 08:34:19
ofst[104]:err_code:0xa0101002, clock:0x2a67d792 2022/07/18 08:34:26
ofst[108]:err_code:0xa0101002, clock:0x2a67d796 2022/07/18 08:34:30
ofst[112]:err_code:0xa0101002, clock:0x2a67d7a0 2022/07/18 08:34:40
ofst[116]:err_code:0xa0101002, clock:0x2a75232a 2022/07/28 10:36:26
ofst[120]:err_code:0xa0101002, clock:0x2a753def 2022/07/28 12:30:39
ofst[124]:err_code:0xa0101002, clock:0x2a753e02 2022/07/28 12:30:58
ofst[ 0]:err_code:0xa0101002, clock:0x2a753e0d 2022/07/28 12:31:09
ofst[ 4]:err_code:0xa0101002, clock:0x2a753e15 2022/07/28 12:31:17
ofst[ 8]:err_code:0xa0101002, clock:0x2a753e76 2022/07/28 12:32:54
ofst[ 12]:err_code:0xa0101002, clock:0x2a753e7f 2022/07/28 12:33:03
ofst[ 16]:err_code:0xa0101002, clock:0x2a753e84 2022/07/28 12:33:08
ofst[ 20]:err_code:0xa0231002, clock:0x2a753e88 2022/07/28 12:33:12

>$ 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] fatalreq delayed.
[ERROR]: 0xa0101002
[SSM] state: 0101 -> 0201
[POWSEQ] AV Backend Setup
[SSM] *** Power Fail RS ***
[SSM] state: 0201 -> 0700
[POWSEQ] AV Backend Letup
[SSM] Shutdown mode : syspm_stat=00000000/00000000
>$
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)

[mullion]$

Bringup : 850 times
Shutdown: 749 times
Power-on: 55day 12hour 56min 20sec
[mullion]$

I'm not sure if this is necessary but after the initial errlogs there are extra error codes with no dates. I assume it's probably normal since I have the board wired up right now to my PC.

*same as above error logs*
ofst[ 24]:err_code:0xa0101002, clock:0xffffffff
ofst[ 28]:err_code:0xa0101002, clock:0xffffffff
ofst[ 32]:err_code:0xa0101002, clock:0xffffffff

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

I already tried looking at the wiki on what a 1002 error could mean and besides pointing at 3 components being involved, it states that it could be the NEC capacitors. Though seeing everything I've read about YLOD diagnosing and RIP-Felix's READTHIS, I want to make sure if everything actually points towards the capacitor or if it could be something else especially besides the A0101002 error I was also getting a A0231002 which I have no idea what it means to have that kind of difference in the power step.

Also possibly unrelated note, my dad previously opened this console around probably 2022/07/18 which might explain the massive amount of recent error logs and before I decided to finally diagnose the syscon the power button doesn't seem to work anymore. Is there any fix for this? I can still touch the power button on the board itself and it works perfectly, I assume it's probably just on the touching part on the case itself.

I apologize if I missed stating anything else, I hope I provided enough information to be helpful!
RSX Tokins most likely. You've read and diagnosed well. Keep calm and carry on good sir! You have my blessing to masacre them tokins.
 
Hello to the community, I'm pretty new to repairing PS3s and decide to give it a shot to repair my old YLOD CECHC04 with COK-002 board. I ran SYSCON and got the following error codes:

00000000 A0801001 0B488681
00000000 A0801200 0B488682
00000000 A0801002 0B488684
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF
00000000 A0404401 FFFFFFFF
00000000 A0403034 FFFFFFFF

After reflowing the RSX it has no longer YLOD and turns on propery so please ignore the first 3 lines about overheating since I powered it on for a few secs with no cooler attached (haven't assembled again to test display output though). So could it be just bad BGA joints that a good reflow or even reballing can fix or the RSX is completely gone and will have YLOD in a few months even with reballing? Also if I understood correctly I could install a 40nm RSX without an orbis mod and modifying the board at all and just by modding it through syscon? Thanks!
the 3034/4xxx is pretty indicative of BGA or Bumps failures. A reball can help if it's the BGA, but if it's the bumps it wont last. You will need to replace the defective GPU. My advice would be to replace the GPU with a 40nm RSX that's not affected by BumpGate. That's the best case scenario for a long term repair. But it's not an easy one.
 
Here's a question for you @M4j0r @sandungas. I know the cell that's installed by sony is set by blowing internal fuses and then it's permanently married to SYSCON and NAND. However, there are NOS Cell BE's on ebay. I'm curious if they haven't been locked yet? If not, would it be possable to install one and then set it? Or would it even need to be set?

Just curious if a NOS Cell could be installed.
 
Here's a question for you @M4j0r @sandungas. I know the cell that's installed by sony is set by blowing internal fuses and then it's permanently married to SYSCON and NAND. However, there are NOS Cell BE's on ebay. I'm curious if they haven't been locked yet? If not, would it be possable to install one and then set it? Or would it even need to be set?

Just curious if a NOS Cell could be installed.
The fuses are blown before CELL gets to the assembly line. It's not possible to do this once CELL is installed. The programming works by using the trace interface which uses a lot of pins with alternate functions, sadly we have no CELL datasheet which contains these nor the protocol being used.
 
Hi there. If someone knows what's reason for 8002f147 error (15% update progress)? Is it software or hardware issue? The motherboard is JTP-001 on 4.82 firmware. Firmware has no error on PS3DumpCheker. The UART terminal (bringup command) shows zero errors in Syscon logs. Just PCI and PCIex disabled.
Thx
 
Hi there. If someone knows what's reason for 8002f147 error (15% update progress)? Is it software or hardware issue? The motherboard is JTP-001 on 4.82 firmware. Firmware has no error on PS3DumpCheker. The UART terminal (bringup command) shows zero errors in Syscon logs. Just PCI and PCIex disabled.
Thx

I hate to be this guy, but have you reformatted or tried a new hard drive yet?
 
PS3 #16 - Mini update

I'm waiting on a thermal camera to arrive. I'm hoping it will tell me which XDR ram chip is not heating up (powering on). Then I'll try replacing it. If they all heat up, then the issue could be the CPU BGA itself. ACE Console repair just had that happen and it caused a similar error...
IMG_4984.jpg
IMG_4998.jpg
IMG_4997.jpg

Anyway his thermal camera saw that it wasn't heating up. He first tried replacing the ram but it didnt work. Then reball. Unfortunately it failed with 3034 and he had to called it unrepairable.

Regardless it's a path forward for me to explore when the cam arrives.

In the meantime this gave me the oppritunity to investigate a theory I have been working on. There are two 65nm RSX models (CXD2982 & CXD2991). The earlier was released in August 2008 in J/K models and only 2 months later was replaced with the latter. Sony "said" they were replacing the 40GB model with the 80GB. But the only the J was 40GB. The K was 80GB. So that sounds like a cover story. What really changed was the MB went from DIA-002 --> VER-001. And the 65nm RSX went from 2982 --> 2991. Why?

The MB was radically redesigned and they were cutting costs to frantically make a profit, so it could just be coincidence. But late 2008 was around the time Nvidia was releasing "fixed" chips. But they were still struggling to understand the defect in thir designs. They were hiring thermal design engineers at the time, signaling they were stumped.

Around that time the fixed chips they released had white underfill material (High Tg). So I wanted to see the underfill material of the these two 65nm chips. To see if there was a color difference to the 90nm, and truely fixed 40nm. I had a 2991, but not a 2982. They are actually kinda rare, since they were only on J and K models. But this MB squeept sent me had one..
20220805_134649.jpg


I didn't like the idea of delidding it, but I litterally could not fin any pictures of a CXD2982 online anywhere! So I did it and found this. @squeept you may be interested in this part. I have questions!
20220805_135417.jpg

20220805_140814.jpg


First, clearly that paste is new! Meaning @squeept delided and used thermal epoxy to reattach the IHS (like a good boy). THIS WAS PERFECT!

Whatever he used it was the right stuff! It was super stiff and I had to apply heat to get it off. 100C for maybe 30s and it loosened then came off really nice. Absolutely the right epoxy. So my first question is, was that the epoxy I reccomended? Or something else. Because now we know what to use.

Second, you can see the underfill isn't white. But it's also not the same color as the 90nm, indicating it's not the same defective underfill as the 90nm..
20220805_111503.jpg


The middle one is a CXD2991. There is perhaps a slight color difference between the two 65nm underfills, but I wouldn't say it's significant enough to conclude they have different ones. It's probably just lighting. I did take these in direct sunlight at the same time, to try and mitigate the effect of exposure and color correction processing. So they are comparable to one another, unlike most photos I've seen on the net. There is a milky whiter color to the 40nm however. The 90nm is greyer. And the 65nm is more brownish.

This tells me the underfill was changed for the 65nm, as expected. Presumably to the proper High Tg needed for High-Lead bumps. That's good, but isn't the full story.

The G9600 was released in feb-2008 with High Tg underfill, High-Lead bumps, and no polyamide stress layer! The PI layer is a coating placed on the die that absorbs and transfers stress from the bumps. It helps protect the dielectris coating underneath from contamination and delamination due to stress. When you use High Tg underfill, yes it protects the bumps from cracking, but it also transfers more stress to the PI and Dielectric layers, making delamination possable. So it's standard to use a certain thickness PI layer to prevent that. And it has been proven with electron micrographs that the G9600 didn't have it! Nvidia traded bump cracking for delamination. The result is the same, the chip dies.

The RSX is not the G96. IDK if it does or does not have the PI layer it should. But I know that chipsets released around the same time, designed by Nvidia's clearly struggling engineers. It's not far fetched to think they may have left the PI layer off the 65nm RSX too. Or perhaps just the 2982. Maybe that's why the 2991 was released only 2 months later and why SONY released the VER-001. To get them fixed fixed chips.

Like I said. It's a theory. And this MB gave me an oppritunity to have a look at a chip I could not get an image of. And it turned out to be useful because it confirms whatever thermal epoxy @squeept used is the perfect stuff to reseal the RSX with.

That's critically important for 90nm at least, Because it's underfill has a Tg of 70C and the RSX routinely runs hotter. The underfill softwns and the bumps crack prematurely. WebMAN can keep the temps below this point if you used dynamic at the default 68C. But good paste is needed to keep fan noise at a minimum. And if you have to delid to achieve this, then tge IHS is no longer stiffening the package and it makes BGA faikures more likly, especially in the corners where the syresses are greatest. Gluing it back on is important for this reasn. And now we know what to use. Or squeept does anyway.
 
And now we know what to use. Or squeept does anyway.

It's the Stars 922 thermal plaster I've shilled for a few times. Consider the tubes to be "two use" - you get to use it once when you open it, then the tip will harden over. For the second use, you snip a corner off of the end and squeeze it out the back. They cost like a buck each in bulk, so it's no big deal.

I forgot to test out the MG epoxy, it's in a drawer somewhere still.
 
Hey all! i havent posted to this site in quite awhile, recently picked up a B01 with GLOD/Artifact. got a 40nm RSX off aliexpress preballed, gonna try and swap the RSX with my home methods, i do not own a reballing machine or anything fancy, but i will be getting a board preheat device, and use a heatgun for the procedure, obviously not professional but i want to see what i can do with what i have, and if it works awesome! if not then it was worth the experience, i have been out of the scene for awhile and its absolutely amazing what everyone has been able to find in the last year and a half! cheers everyone! ill report my results once i get everything;)
 

Similar threads

Back
Top