Hi All.
I have an 820-02016 board (A2337 M1) that has come in for data recovery. Reported as liquid damage, but no visible evidence of any liquid damage.
Board was initially stuck at 5v, and current only spiking occasionally to around 400mA and cycling.
After initial troubleshooting, found that C7800 (which feeds the power rail PP5V_BSTLQ_VOUT_SPMU) was dead short to ground.
Replaced C7800 and short gone. Board still stuck at 5v. Current draw behaviour changed. It now spikes up for a second to around 100mA to 130mA, then drops down to around 45mA, then zero for a second or so, then resets and process starts over. Doing the same thing on both USB-C ports.
Can't seem to find any other shorts.
Have tried the see if it is stuck in DFU mode, but doesn't show in DFU at all, so doesn't seem to be stuck in DFU mode.
Measured voltages:
CD3217 support voltages:
PP3V3_S2_UPC: pulsing – Unsure of voltage (no scope) – 0.44v diode mode to ground
PP5V_S2: 0v - 0.264v diode mode to ground
PP1V25_S2: pulsing – Unsure of voltage (no scope) – 0.252v diode mode to ground
Other voltages:
PP3V8_AON_VDDMAIN: 3.79v
PPBUS_AON: 12.28v
P5VS2_PWR_EN: 0v
P5VS2_EN: 0v - 0.348v diode mode to ground
PPBUS_5V_S2_VIN: 12.28v
So based on this, my guess is that U8100 is bad (seeing as P5VS2_EN is missing and is produced by U8100) and possibly U7700.
The only thing worrying me is that the diode mode test for P5VS2_EN still looks fine compared to the readings listed on openboarddata.org for P5VS2_EN and to my working donor board. Also, it seems strange that the initial short was related to a rail that is produced by U7700, but the missing enable is generated by U8100. I am not sure how these 2 chips interact with each other but hopefully someone else may have a better idea.
I am thinking of swapping out U8100 and possibly U7700 from the donor to see if that sorts out the issue.
So, based on this plan I have 2 questions:
1) Does replacing U8100 and/or U7700 sound like the right way to go, or could there be some other reason why U8100 isn't producing the P5VS2_EN enable signal? What else could cause this type of behaviour?
2) If I replace U8100 and U7700 will data remain intact? As in assuming that replacing U8100/U7700 gets the board working again, would I still be able to recover the client's data, or does replacing U8100/U7700 mean that a DFU is required to get the board running after replacement? As mentioned, the board is here for data recovery, so don't want to attempt anything that could put the data at risk.
Thanks in advance for the help, and any/all help is appreciated.
I have an 820-02016 board (A2337 M1) that has come in for data recovery. Reported as liquid damage, but no visible evidence of any liquid damage.
Board was initially stuck at 5v, and current only spiking occasionally to around 400mA and cycling.
After initial troubleshooting, found that C7800 (which feeds the power rail PP5V_BSTLQ_VOUT_SPMU) was dead short to ground.
Replaced C7800 and short gone. Board still stuck at 5v. Current draw behaviour changed. It now spikes up for a second to around 100mA to 130mA, then drops down to around 45mA, then zero for a second or so, then resets and process starts over. Doing the same thing on both USB-C ports.
Can't seem to find any other shorts.
Have tried the see if it is stuck in DFU mode, but doesn't show in DFU at all, so doesn't seem to be stuck in DFU mode.
Measured voltages:
CD3217 support voltages:
PP3V3_S2_UPC: pulsing – Unsure of voltage (no scope) – 0.44v diode mode to ground
PP5V_S2: 0v - 0.264v diode mode to ground
PP1V25_S2: pulsing – Unsure of voltage (no scope) – 0.252v diode mode to ground
Other voltages:
PP3V8_AON_VDDMAIN: 3.79v
PPBUS_AON: 12.28v
P5VS2_PWR_EN: 0v
P5VS2_EN: 0v - 0.348v diode mode to ground
PPBUS_5V_S2_VIN: 12.28v
So based on this, my guess is that U8100 is bad (seeing as P5VS2_EN is missing and is produced by U8100) and possibly U7700.
The only thing worrying me is that the diode mode test for P5VS2_EN still looks fine compared to the readings listed on openboarddata.org for P5VS2_EN and to my working donor board. Also, it seems strange that the initial short was related to a rail that is produced by U7700, but the missing enable is generated by U8100. I am not sure how these 2 chips interact with each other but hopefully someone else may have a better idea.
I am thinking of swapping out U8100 and possibly U7700 from the donor to see if that sorts out the issue.
So, based on this plan I have 2 questions:
1) Does replacing U8100 and/or U7700 sound like the right way to go, or could there be some other reason why U8100 isn't producing the P5VS2_EN enable signal? What else could cause this type of behaviour?
2) If I replace U8100 and U7700 will data remain intact? As in assuming that replacing U8100/U7700 gets the board working again, would I still be able to recover the client's data, or does replacing U8100/U7700 mean that a DFU is required to get the board running after replacement? As mentioned, the board is here for data recovery, so don't want to attempt anything that could put the data at risk.
Thanks in advance for the help, and any/all help is appreciated.
Comment