PS5 Pro BLOD - UART codes 808C4F90 and C0020303. USB-C issue?

  • Thread starter Thread starter korsar86
  • Start date Start date
  • Views Views 416
  • Replies Replies 5

korsar86

New Member
Newbie
Joined
May 23, 2026
Messages
4
Reaction score
0
Trophies
0
Age
37
XP
16
Country
Turkmenistan
Hi guys,
I have a PS5 Pro (VSM-010) stuck on BLOD.
UART gives me these codes: 808C4F90, 808C3790, C0020303, 80000009.
All APU power rails are fine (around 0.9V), no shorts in the VRM area, and the board warms up evenly.
Based on the attached screenshot, am I right to think that 808Cxxxx is the primary error pointing to a USB-C controller/muxer issue? Should I focus on the S2MMC01X01 chip first, and C0020303 is just a consequence?
Any advice is appreciated. Thanks!
 

Attachments

  • IMG_20260523_150517.png
    IMG_20260523_150517.png
    1.3 MB · Views: 6
Any thoughts on this?
Just to move forward with diagnostics, can I safely desolder the S2MMC01X01 chip or the TUSB44 muxer to see if the error code changes? I want to check if removing one of them releases the I2C bus and clears the 808Cxxxx error.
Or will the console completely refuse to boot without these chips present?
Thanks for any hints!


 
808C4F90/3790 can point to a peripheral init or power sequence issue, but I would not assume USB C immediately. C0020303 is often secondary when something earlier in init hangs.

Before removing S2MMC or the TUSB mux, check the I2C lines first. Measure SDA/SCL resistance to ground and see if either line is stuck low during boot. Also verify all local rails around the USB C area, especially 3.3V, enable and reset signals.

You can temporarily isolate the bus by lifting the I2C pullups or series resistors instead of fully desoldering the ICs. Safer and faster for diagnostics.

Did you already check for activity on the I2C bus with a scope or logic analyzer?
 
  • Like
Reactions: korsar86
808C4F90/3790 can point to a peripheral init or power sequence issue, but I would not assume USB C immediately. C0020303 is often secondary when something earlier in init hangs.

Before removing S2MMC or the TUSB mux, check the I2C lines first. Measure SDA/SCL resistance to ground and see if either line is stuck low during boot. Also verify all local rails around the USB C area, especially 3.3V, enable and reset signals.

You can temporarily isolate the bus by lifting the I2C pullups or series resistors instead of fully desoldering the ICs. Safer and faster for diagnostics.

Did you already check for activity on the I2C bus with a scope or logic analyzer?
Thanks for the great advice, lifting the series resistors instead of desoldering the whole IC was a lifesaver!Before pulling them, I checked the SDA/SCL lines to ground on an unpowered board, and they measured totally fine at around 9k Ohms.
I desoldered the two resistors to isolate the JM=CC (S2MMC) chip from the bus, the original 808C4F90 and 3790 power errors completely disappeared. The APU initialization error (C0020303) went away too.Now, the console behaves differently. In standby, it constantly spits out a single error: 808C3090, which makes sense since the chip is disconnected. When I press power, it shows that same code for a few seconds, and then the UART log goes completely silent while the blue light just blinks.I don't have a scope to check the I2C activity in real-time, but seeing how all the main power errors and the APU hang vanished after cutting off the chip, it really looks like it was glitching the bus during boot.Do you think it's safe to say the S2MMC chip is dead and needs to be replaced now?
Post automatically merged:

P.S.Actually, scratch that! I just re-tested it and kept spamming the log button even faster during boot.Right after pressing power, I first get 808C3090, but then a second later C0020303 pops up anyway. After that, everything goes completely silent.So it looks like the APU is still hanging, and the Southbridge just shuts down the boot sequence so fast that the APU error usually gets cut off before I can see it.Honestly, now I'm completely confused again. Any ideas on what to check next?
Post automatically merged:

IMG_20260527_181833.png
 
Last edited by korsar86,
View attachment 575185

View attachment 575186

Maybe this both maps may help to find the issue.
Thanks for the maps! I just checked all the measurements around both ICs, and everything looks totally fine. The values are very close to your sheets, just minor differences due to board variation.
Also, after re-testing the isolated bus, I am now constantly getting both 808C3090 and C0020303 together.
Does this mean that the Type-C logic is working properly?
After all, the main issue is still error code C0020303, and it’s a problem with the APU itself...(
 

Site & Scene News

Popular threads in this forum