PS3 (Research/Experimental) - NEC/TOKIN Capacitors Replacement - YLOD

[RIP-Felix]

As requested by RIP-Felix I have pulled the errlog using syscon per the instructions in this post. I've been really busy with summer activities so this was put on the backburner for a few weeks.

To summarize my first reply in this thread, I have (4) PS3's. My old CECHH that YLOD'd many years ago, and a CECHA and CECHB that I grabbed for cheap on FB Marketplace. The fourth is a ceramic white CECHL import that has never been tampered with and runs fine (for now). I jumped ahead and recapped the NEC/TOKINs on the H, A and B based on early feedback on this thread, and may have inadvertently reconnected/reflowed BGAs during the process. The H, A and B all came back to life and are still working. I delidded the A and B, the model A's RSX did not survive the delidding. The delidding was very successful on the model B.

I have ordered a 90nm RSX and a couple of NOS 40nm RSX to revive the model A in the future. I'm planning to do the "Frankenstein Phat" mod. I grabbed an extra 40nm for the assumed eventual failure of the model B.

I'll re-re-cap the H, A and B with the PS3 Tantalizer v0.2b and Panny 2R5TPE470M7 at some point down the line to get it back in spec.

The model A is dismembered into many bags and is not in any condition to pull codes.

Anyway, here is the errlog from the Model H:

ofst[ 80]:err_code:0xffffffff, clock:0xffffffff
ofst[ 84]:err_code:0xa0403034, clock:0xffffffff
ofst[ 88]:err_code:0xa0404412, clock:0xffffffff
ofst[ 92]:err_code:0xa0403034, clock:0xffffffff
ofst[ 96]:err_code:0xa0404412, clock:0xffffffff
ofst[100]:err_code:0xa0403034, clock:0xffffffff
ofst[104]:err_code:0xa0404412, clock:0xffffffff
ofst[108]:err_code:0xa0403034, clock:0xffffffff
ofst[112]:err_code:0xa0404412, clock:0xffffffff
ofst[116]:err_code:0xa0403034, clock:0xffffffff
ofst[120]:err_code:0xa0404412, clock:0xffffffff
ofst[124]:err_code:0xa0403034, clock:0xffffffff
ofst[  0]:err_code:0xa0404412, clock:0xffffffff
ofst[  4]:err_code:0xa0403034, clock:0xffffffff
ofst[  8]:err_code:0xa0404412, clock:0xffffffff
ofst[ 12]:err_code:0xa0403034, clock:0xffffffff
ofst[ 16]:err_code:0xa0404412, clock:0xffffffff
ofst[ 20]:err_code:0xa0403034, clock:0xffffffff
ofst[ 24]:err_code:0xa0404412, clock:0xffffffff
ofst[ 28]:err_code:0xa0403034, clock:0xffffffff
ofst[ 32]:err_code:0xa0404412, clock:0xffffffff
ofst[ 36]:err_code:0xa0403034, clock:0xffffffff
ofst[ 40]:err_code:0xa0404412, clock:0xffffffff
ofst[ 44]:err_code:0xa0403034, clock:0xffffffff
ofst[ 48]:err_code:0xa0404412, clock:0xffffffff
ofst[ 52]:err_code:0xa0403034, clock:0xffffffff
ofst[ 56]:err_code:0xa0404412, clock:0xffffffff
ofst[ 60]:err_code:0xa0403034, clock:0xffffffff
ofst[ 64]:err_code:0xa0404412, clock:0xffffffff
ofst[ 68]:err_code:0xa0403034, clock:0xffffffff
ofst[ 72]:err_code:0xa0404412, clock:0xffffffff
ofst[ 76]:err_code:0xa0403034, clock:0xffffffff

And here is the errlog from the Model B:

ofst[  0]:err_code:0xa0801601, clock:0xffffffff
ofst[  4]:err_code:0xa0403034, clock:0x1147ad5f  2009/03/09 10:35:11
ofst[  8]:err_code:0xa0403034, clock:0x1147ad72  2009/03/09 10:35:30
ofst[ 12]:err_code:0xa0403034, clock:0x1147ad7e  2009/03/09 10:35:42
ofst[ 16]:err_code:0xa0403034, clock:0x1147ad86  2009/03/09 10:35:50
ofst[ 20]:err_code:0xa0403034, clock:0x11c4a69a  2009/06/12 05:39:38
ofst[ 24]:err_code:0xa0403034, clock:0x11c4a6ba  2009/06/12 05:40:10
ofst[ 28]:err_code:0xa0403034, clock:0x11c4a6d7  2009/06/12 05:40:39
ofst[ 32]:err_code:0xa0403034, clock:0x11c4a95e  2009/06/12 05:51:26
ofst[ 36]:err_code:0xa0403034, clock:0x11c4a96c  2009/06/12 05:51:40
ofst[ 40]:err_code:0xa0403034, clock:0x11c4a979  2009/06/12 05:51:53
ofst[ 44]:err_code:0xa0403034, clock:0x11c4aa6b  2009/06/12 05:55:55
ofst[ 48]:err_code:0xa0403034, clock:0x11c4aa79  2009/06/12 05:56:09
ofst[ 52]:err_code:0xa0403034, clock:0x132b2884  2010/03/11 04:05:24
ofst[ 56]:err_code:0xa0403034, clock:0x132b2889  2010/03/11 04:05:29
ofst[ 60]:err_code:0xa0403034, clock:0x132b288e  2010/03/11 04:05:34
ofst[ 64]:err_code:0xa0403034, clock:0x132b2893  2010/03/11 04:05:39
ofst[ 68]:err_code:0xa0403034, clock:0x132b2897  2010/03/11 04:05:43
ofst[ 72]:err_code:0xa0403034, clock:0x132b289b  2010/03/11 04:05:47
ofst[ 76]:err_code:0xa0403034, clock:0x132b28a1  2010/03/11 04:05:53
ofst[ 80]:err_code:0xa0403034, clock:0x132b28a6  2010/03/11 04:05:58
ofst[ 84]:err_code:0xa0403034, clock:0x132b28aa  2010/03/11 04:06:02
ofst[ 88]:err_code:0xa0403034, clock:0x132b28ad  2010/03/11 04:06:05
ofst[ 92]:err_code:0xa0403034, clock:0x133f1951  2010/03/26 07:05:53
ofst[ 96]:err_code:0xa0403034, clock:0xffffffff
ofst[100]:err_code:0xa0403034, clock:0xffffffff
ofst[104]:err_code:0xa0403034, clock:0xffffffff
ofst[108]:err_code:0xa0403034, clock:0xffffffff
ofst[112]:err_code:0xa0801002, clock:0x0b4886ab  2005/12/31 00:00:43
ofst[116]:err_code:0xa0801002, clock:0x0b4887ee  2005/12/31 00:06:06
ofst[120]:err_code:0xa0801001, clock:0x0b488bd7  2005/12/31 00:22:47
ofst[124]:err_code:0xa0801001, clock:0x0b667ee0  2006/01/22 17:35:28

H model = Reball Candidate
B model = Had the perfect sole 3034 that I was looking for to install the 40nm RSX for the Frankenstein Mod. So that would be a good candidate for it. You say it booted after the Tantalum swap. I can see that in the error log, along with the tell-tale signs that the tantalums solution you used wasn't adequate for the filter (1002's). The last 2 errors are usually associated with flipping pwr rocker off without gracefully shutting down first. So I'm guessing you redid the tantalums and fixed the filter?

I'm glad you are interested in doing the frankenstein mod! So far it's just @squeept and I who have attempted it on a COK-001. Others have tried COK-002. As such, it's still experimental. I'm currently having an issue with PS2 games being stuck on a black screen. Sometimes it crashes upon restart of the PS2 HW with an 80 1701. I would like to know if that is because my board had faulty PS2 HW, or if the mod could be causing it. So the more of us attempting the mod, the more chances of figuring it out.

Good luck!

 

[truemaster]

no i can confirm the 40nm rsx not is not the reasson for bad ps2 compatibility. the video you posted at page 205 at the end he plays a ps2 game. your differences are his ps3 is a cok-002 and yours is a cok-001

 

[DeadEnd]

no i can confirm the 40nm rsx not is not the reasson for bad ps2 compatibility. the video you posted at page 205 at the end he plays a ps2 game. your differences are his ps3 is a cok-002 and yours is a cok-001

In that video I was using the cok002 board with a 65nm RSX without the voltage mod.

 

[truemaster]

ahh thats a difference that might be why he has ps2 problems. that surely needs to be cleared.

 

[RIP-Felix]

no i can confirm the 40nm rsx not is not the reasson for bad ps2 compatibility. the video you posted at page 205 at the end he plays a ps2 game. your differences are his ps3 is a cok-002 and yours is a cok-001

The voltage mod to Q6200 isn't needed for that chip. So there another difference. Not that it should matter.

Perhaps the COK-001 with it's EE+GS chip is at fault. It's still experimental. So, IDK yet.

 

[truemaster]

yeah those difference might be. rather not ofcource 40nm on a cecha is amazing

 

[Pacorretaco]

H model = Reball Candidate
B model = Had the perfect sole 3034 that I was looking for to install the 40nm RSX for the Frankenstein Mod. So that would be a good candidate for it.

At this point I'm pretty sure it can be the same thing.
The same problem being reported in different way.
Simply COK-001 being more primitive, and only reporting 3034 instead of 3034+44XX.
But if you look at the bringup, you could see how even the 3034 alone was mentioning the same RSX error, yet without the 44xx.
Maybe it's something they updated to try and make it less ambiguous... After all they maybe had the same head scratching we are having now at some point.

Otherwise I'd say you got it backwards. If anything, it's the 44xx precisely the distinctive RSX error.

3034 alone by itself is a CPU error. Nothing explicit about RSX. So yeah imagine swapping out the RSX after seeing 3034 when actually the issue was CPU... Or southbridge.
That's why bringup is necessary.
Not saying it is your case. Just a matter of language.

 

[RIP-Felix]

At this point I'm pretty sure it can be the same thing.
The same problem being reported in different way.
Simply COK-001 being more primitive, and only reporting 3034 instead of 3034+44XX.
But if you look at the bringup, you could see how even the 3034 alone was mentioning the same RSX error, yet without the 44xx.
Maybe it's something they updated to try and make it less ambiguous... After all they maybe had the same head scratching we are having now at some point.

Otherwise I'd say you got it backwards. If anything, it's the 44xx precisely the distinctive RSX error.

3034 alone by itself is a CPU error. Nothing explicit about RSX. So yeah imagine swapping out the RSX after seeing 3034 when actually the issue was CPU... Or southbridge.
That's why bringup is necessary.
Not saying it is your case. Just a matter of language.

I disagree.

I've had COK-001 boards with the 44xx data error associated with the 3034 too. The frankenstein I just completed was a sole 3034. If it was a CPU error then it shouldn't have worked until I reflow the CPU as well (unless it is a false positive and the strain hasn't relaxed yet). IMO, it depends on which BGA pads disconnect whether or not there's a data error. This is speculation, but perhaps the lone 3034 happens when a BGA for voltage pops. And if it happens on the RX/TX lines you get 3034/44xx. Or visa-versa...IDK. Regardless, the solution is the same. Reball!

Normally you don't know which chip it is. We assume the RSX because it has a more varied load. More thermal cyclces even thought it has a lower delta T = sooner failure.

Spoiler: Anecdote.

That and something about it's design could be making it less reliable too. I wonder if the diamond arrangement with RAM on the corners affected the deformation pattern. Perhaps it exacerbated the BGA failure. However, I would expect it to have been redesigned if that were the case, and the diamond design lasted until the 28nm SS models.

I think they were mostly concerned with the heat and cost savings that miniaturization afforded. However, they did go to a standard square design for the 28nm RSX. Although they put the hot die close to the FlexIO BGA. They apparently, prioritized minimizing trace distance over minimizing the Delta T over the FlexIO BGA (they could have mirrored the design and placed the die on the other side). So again, I think they were not really concerned with it. Trace distance makes a bigger difference in performance, they probably calculated.

 

[Pacorretaco]

I disagree.

I've had COK-001 boards with the 44xx data error associated with the 3034 too. The frankenstein I just completed was a sole 3034. If it was a CPU error then it shouldn't have worked until I reflow the CPU as well (unless it is a false positive and the strain hasn't relaxed yet). IMO, it depends on which BGA pads disconnect whether or not there's a data error. This is speculation, but perhaps the lone 3034 happens when a BGA for voltage pops. And if it happens on the RX/TX lines you get 3034/44xx. Or visa-versa...IDK. Regardless, the solution is the same. Reball!

Normally you don't know which chip it is. We assume the RSX because it has a more varied load. More thermal cyclces even thought it has a lower delta T = sooner failure.

Spoiler: Anecdote.

That and something about it's design could be making it less reliable too. I wonder if the diamond arrangement with RAM on the corners affected the deformation pattern. Perhaps it exacerbated the BGA failure. However, I would expect it to have been redesigned if that were the case, and the diamond design lasted until the 28nm SS models.

I think they were mostly concerned with the heat and cost savings that miniaturization afforded. However, they did go to a standard square design for the 28nm RSX. Although they put the hot die close to the FlexIO BGA. They apparently, prioritized minimizing trace distance over minimizing the Delta T over the FlexIO BGA (they could have mirrored the design and placed the die on the other side). So again, I think they were not really concerned with it. Trace distance makes a bigger difference in performance, they probably calculated.

Hmm so it's not that then?
It's only on COK 001 boards that I've seen lone 3034 when there's RSX still mentioned in brittaning.

If so, then what do you mean when you say this?

B model = Had the perfect sole 3034 that I was looking for to install the 40nm RSX for the Frankenstein Mod. So that would be a good candidate for it

Why do you "prefer" 3034 alone?
If you say it's actually not the same as 3034+44xx, then doesn't that make the problem less obvious instead of more?
I mean even in the manual 3034 lazily listed as "CPU" error. Nothing about RSX.

I'm from Europe so I've not seen very many COK 001 boards after all. But the ones I've seen did not have 4xxx whereas the COK 002 and newer always do. Even if bringup says pretty much the same.

Edit: If you find one of those COK 001 with 3034+44xx would you mind typing these commands to see?

hversion
version
revision

 

[RIP-Felix]

Hmm so it's not that then?
It's only on COK 001 boards that I've seen lone 3034 when there's RSX still mentioned in brittaning.

If so, then what do you mean when you say this?

Why do you "prefer" 3034 alone?
If you say it's actually not the same as 3034+44xx, then doesn't that make the problem less obvious instead of more?
I mean even in the manual 3034 lazily listed as "CPU" error. Nothing about RSX.

I'm from Europe so I've not seen very many COK 001 boards after all. But the ones I've seen did not have 4xxx whereas the COK 002 and newer always do. Even if bringup says pretty much the same.

Edit: If you find one of those COK 001 with 3034+44xx would you mind typing these commands to see?

hversion
version
revision

Yeah so...

Spoiler: PS3#2 had a 3034/4002

I've seen sole 3034 and 3034/4xxx on COK-001's with BGA issues. It's a crap shoot. The reason I "hoped" for a sole 3034 was based on the "emotional" comfort. A single error seems less bad than two. It's wasn't based off any rational reason, I was just speculating that a sole 3034 might mean fewer BGA pads have broken. I have no reason to believe this is true. Nor do I rationally think it makes any difference for the frankenstein mod or reball. Frankly, either one would be a good candidate.

Unforthunately, PS3#2 is dead. I tokin modded it's brains out, pulled the RSX off the board, attempted reballs 3 times, tearing pads and traces from the board. It's dead dead! However, I wonder if I plugged it in if I could retrieve the syscon stuff you asked for? I mean, it doesn't need an RSX for that does it?

 

[RIP-Felix]

@vyktormvmpay25 I modified the RSX PWR pinout to include the VDDA pads that are not connected on the RSX. Also I made a mirror of it for both the motherboard and RSX views. The color legend now reads the voltages too. This makes it easier to know what voltage you should be getting (ball park).

Spoiler: RSX PWR Pinout (MB View)

Spoiler: RSX PWR Pinout (RSX View)

I thought you might like to add them to your shared folder so everyone can access them via the link you shared. I have linked to it multiple times before.

 

[vyktormvmpay25]

RIP-Felix added photos to cloud
http://s.go.ro/ax49drsu.
Syscon can be accessed without cpu/rsx on board, just make sure no pads are shorted.

 

[Pacorretaco]

Yeah so...

Spoiler: PS3#2 had a 3034/4002

View attachment 34242

I've seen sole 3034 and 3034/4xxx on COK-001's with BGA issues. It's a crap shoot. The reason I "hoped" for a sole 3034 was based on the "emotional" comfort. A single error seems less bad than two. It's wasn't based off any rational reason, I was just speculating that a sole 3034 might mean fewer BGA pads have broken. I have no reason to believe this is true. Nor do I rationally think it makes any difference for the frankenstein mod or reball. Frankly, either one would be a good candidate.

Unforthunately, PS3#2 is dead. I tokin modded it's brains out, pulled the RSX off the board, attempted reballs 3 times, tearing pads and traces from the board. It's dead dead! However, I wonder if I plugged it in if I could retrieve the syscon stuff you asked for? I mean, it doesn't need an RSX for that does it?

Sure, as long as there is a red light, you should be able to talk to the SYSCON. The RSX may as well be missing altogether.

But is interesting how the error is 4002. I wonder if the more typical 44XX are the ones that aren't implemented?

Talking about RSX pads, I wonder if your ps3#2 could still have some hope left after all?
In those pictures the pinout can be seen, but they mix the N/C and the data pads which is a bit unfortunate.
What I'm doing is just assuming a pad in the board is N/C if i don't see anything with my eyes.
On the board that came with missing RSX and 35 pads, most of them seem N/C, which makes sense since they should be the weakest. I think only 12 actually were connected somewhere and I think I'm done.
But of course who knows if it'll actually work with so much damage. I've never done anything like this before either.

 

[vyktormvmpay25]

Worth a try anyway. You are right about N/C pads if there isn't any trace going to it just ignore it.

 

[MuNaught]

H model = Reball Candidate
B model = Had the perfect sole 3034 that I was looking for to install the 40nm RSX for the Frankenstein Mod. So that would be a good candidate for it. You say it booted after the Tantalum swap. I can see that in the error log, along with the tell-tale signs that the tantalums solution you used wasn't adequate for the filter (1002's). The last 2 errors are usually associated with flipping pwr rocker off without gracefully shutting down first. So I'm guessing you redid the tantalums and fixed the filter?

I'm glad you are interested in doing the frankenstein mod! So far it's just @squeept and I who have attempted it on a COK-001. Others have tried COK-002. As such, it's still experimental. I'm currently having an issue with PS2 games being stuck on a black screen. Sometimes it crashes upon restart of the PS2 HW with an 80 1701. I would like to know if that is because my board had faulty PS2 HW, or if the mod could be causing it. So the more of us attempting the mod, the more chances of figuring it out.

Good luck!

I'm going to do the Frankstein mod on the model A first, since that RSX is toast and I've confirmed at a minimum the motherboard should be fine. The model B will be a potential future mod if/when it YLOD's again.

The 1002's are probably from one or more bad solder joints. The model B was the last of the three, so after 200+ solder joints (2x32 each plus jumpers) I wasn't being as cautious. I went back in and cleaned it up.

 

[hardtecnica]

I'm in a similar bot. I have the cech2001b. Delided, loads into xmb, loads into gta5, ylods almost at the exact same place (first mission post detonating the doors). After that, it ylods in the xmb. I leave it alone for a while and it loads fine. Until I put stress (gta5 or gta4). I dumped the Syscon, had errors 14ff and 1701.

on a separate topic...rips posts on the Frankie phat are an amazing read. Way to go!

Did the less intrusive tantalum mod possible in my beloved 2001A. Used just one 330uf 2.5v for test, no damage made to the Nectokin since I jumped to avoid any contact from the iron on the corner and used 4 layers of paper tape to protect it from direct contact, 50W 510° iron solder was perfect to instantly melt, never try doing it with just 30W, PCB will dissipate all the heat. Since it was a weak YLOD (the one who only happened randomly in games and instantly on F1 2013) it just worked and no more Ylods so far. Unfortunately I can't do the SYSCON thing since it would be very hard to find the cable, so this mod was the easy way. Let's see how long it will endure and hope it was indeed a Nectokin issue, no extra pressure on the bracket, so the theory of BGA e my case is very hypothetical.

 

[Kleon1876]

Here is something i never seen before. This is my 2000a slim which i delided. On cold boot, GLOD for about half a minute, then beep and shutdown. Subsequent attempts, 2-3 second ylod. After 10+ tries, console works no problem. I turn off, turn on everything fine, no crashes, no shutdowns. Leave for the night. Cycle repeats. So today, instead of booting up cold (from overnight being off), i decided to hook it up to the syscon GUI and use the execute command bringup. instead of glod, it ylod on first try. subsequent attempt, it booted, console beeped...then beeped again...booted. Dumbed the codes and this is what i got....
===================================
ERR 00: FFFFFFFF Answer length
ERR 01: FFFFFFFF Checksum
ERR 02: 00000000 A0801201 0B4D061A
ERR 03: 00000000 A0801201 0B4D0588
ERR 04: 00000000 FFFFFFFF FFFFFFFF
ERR 05: 00000000 FFFFFFFF FFFFFFFF
ERR 06: 00000000 FFFFFFFF FFFFFFFF
ERR 07: 00000000 FFFFFFFF FFFFFFFF
ERR 08: 00000000 FFFFFFFF FFFFFFFF
ERR 09: 00000000 FFFFFFFF FFFFFFFF
ERR 10: 00000000 FFFFFFFF FFFFFFFF
ERR 11: 00000000 FFFFFFFF FFFFFFFF
ERR 12: 00000000 FFFFFFFF FFFFFFFF
ERR 13: 00000000 FFFFFFFF FFFFFFFF
ERR 14: 00000000 FFFFFFFF FFFFFFFF
ERR 15: 00000000 FFFFFFFF FFFFFFFF
ERR 16: 00000000 FFFFFFFF FFFFFFFF
ERR 17: 00000000 FFFFFFFF FFFFFFFF
ERR 18: 00000000 FFFFFFFF FFFFFFFF
ERR 19: 00000000 FFFFFFFF FFFFFFFF

thoughts? I think this whole cold boot might have something to do with the checksum since prior to delid etc i dumped the codes and hooked it up to uart. Not sure, if it messed the syscon up and is now stuck in this weird glod first, ylod, and finally boot after 20 attempts. Also its not the power supply, cuz i have a 2000b with a wokring powersupply which i used on the "A" model and same thing. I used th "A" model suspect power supply and on the "B" model and worked on first try. I thought NECS..but my "A" model only has necs on the RSX. Thoughts?

 

[RIP-Felix]

Here is something i never seen before. This is my 2000a slim which i delided. On cold boot, GLOD for about half a minute, then beep and shutdown. Subsequent attempts, 2-3 second ylod. After 10+ tries, console works no problem. I turn off, turn on everything fine, no crashes, no shutdowns. Leave for the night. Cycle repeats. So today, instead of booting up cold (from overnight being off), i decided to hook it up to the syscon GUI and use the execute command bringup. instead of glod, it ylod on first try. subsequent attempt, it booted, console beeped...then beeped again...booted. Dumbed the codes and this is what i got....
===================================
ERR 00: FFFFFFFF Answer length
ERR 01: FFFFFFFF Checksum
ERR 02: 00000000 A0801201 0B4D061A
ERR 03: 00000000 A0801201 0B4D0588
ERR 04: 00000000 FFFFFFFF FFFFFFFF
ERR 05: 00000000 FFFFFFFF FFFFFFFF
ERR 06: 00000000 FFFFFFFF FFFFFFFF
ERR 07: 00000000 FFFFFFFF FFFFFFFF
ERR 08: 00000000 FFFFFFFF FFFFFFFF
ERR 09: 00000000 FFFFFFFF FFFFFFFF
ERR 10: 00000000 FFFFFFFF FFFFFFFF
ERR 11: 00000000 FFFFFFFF FFFFFFFF
ERR 12: 00000000 FFFFFFFF FFFFFFFF
ERR 13: 00000000 FFFFFFFF FFFFFFFF
ERR 14: 00000000 FFFFFFFF FFFFFFFF
ERR 15: 00000000 FFFFFFFF FFFFFFFF
ERR 16: 00000000 FFFFFFFF FFFFFFFF
ERR 17: 00000000 FFFFFFFF FFFFFFFF
ERR 18: 00000000 FFFFFFFF FFFFFFFF
ERR 19: 00000000 FFFFFFFF FFFFFFFF

thoughts? I think this whole cold boot might have something to do with the checksum since prior to delid etc i dumped the codes and hooked it up to uart. Not sure, if it messed the syscon up and is now stuck in this weird glod first, ylod, and finally boot after 20 attempts. Also its not the power supply, cuz i have a 2000b with a wokring powersupply which i used on the "A" model and same thing. I used th "A" model suspect power supply and on the "B" model and worked on first try. I thought NECS..but my "A" model only has necs on the RSX. Thoughts?

Have you tried checking and fixing the checksum?

Auth in manually. Use eepcsum command to see if its wrong. Then write the "should be" value in. You can use the tutorials to figure it out or we can walk you through it.

 

[Kleon1876]

Have you tried checking and fixing the checksum?

Auth in manually. Use eepcsum command to see if its wrong. Then write the "should be" value in. You can use the tutorials to figure it out or we can walk you through it.

I can't access it via cmd/python. I have no problem doing the cxr fat models but the same SW command isn't working for me. Is there something else I have to have installed in python specifically for sw Syscons?

 

[RIP-Felix]

Try again being careful to follow the steps. Be sure you have the python dependencies. Use cmd terminal. Double check the USB com port. And be sure to use SW. You do not need diag wire.

If the exe works, then the manual way must.