M1 A2338 screen and touchbar issues after cleaning up liquid damage

[jkruns]

Hello everyone,

This is my first post after browsing this wonderful treasure trove of knowledge for many, many evenings. I've decided to learn how to fix these things, properly.

My patient is an A2338 Macbook Pro M1 (late 2020).

It had some corrosion around JT710 and JT700 caused by liquid spill, as well as against the protective barrier around the USB-C chips UF000 and UF100. So I took the main board out and cleaned it with a toothbrush and alcohol, then with alcohol in an ultrasonic cleaner. Cleaned the touchbar flex connectors as well. The board looks immaculate.
It will now boot, also from battery. Only issues are, the touchbar does not respond to touch and the screen displays a 3 inch wide vertical band on the far right where the picture is 50 percent less bright. Sometimes it flickers slightly.

The weird thing is, at the login screen, the dark band displays the actual desktop from when I was last logged in. With browser windows and all. It's like you take a screenshot of your desktop and show the leftmost 3 inch on the login screen, only a lot darker.

The same main board in a different A2338 M1 chassis works fine (both screen and touchbar). From this you would conclude the issue is with the screen assembly itself (or the flex cable) and with the touchbar flex cable. I have replaced both with specimens from a working Macbook, which did not solve the problem.

My questions are these:

• Given that the problem with the display seems to be with the display assembly itself and not the main board, is there something I can take a look at in the display electronics attached to the display assembly? If the flex cables that run to the display itself are somehow damaged I presume this means it cannot be fixed, right?
• Cleaning up JT710 and JT700 was clearly not enough. I will go over the schematics and openboardview again to see what I can measure and where, but in the mean time any suggestions are welcome.
• What explains the weird desktop caching on the login screen? I agree it's most likely not a hardware related issue, but nevertheless an interesting one.
• How do you replace the black protective film covering some of the chips? You can't pull them off without at least warping or damaging them a bit, and they won't stick as well anymore. Do you just stick the old ones back and hope they don't come loose? Or cut new ones from a sheet of adhesive material?

Thank you for reading.

[jkruns]

Update: I put the working main board in another M1 Pro chassis, including touch id button/sensor.
This solved the display and touchbar issues, but introduced other problems.

The battery is not charging and I can only turn it on by pressing control-option-rightshift-poweron.
It boots normally, but the battery is not charging ('service recommended') and the fan kicks in at 100 percent. I know the battery is good, but to be sure I connected a spare battery which gave me the same issue (swapped the flex cable as well).

When the MacBook is off but plugged in to the charger, I can see the voltage constantly going up and down at the fuse F5200 (from 0 to 12V and back again). At numerous other points I can see for example the 3v8 rail oscillating between 1.5 to 3.8V. The fuse itself is ok though.

So it seems the cleanup job left some damage untouched, or maybe it's a new issue.
I have the obv file and the schematics and I'm learning about which components control voltage and how. In the meantime I would really appreciate it if this sounds familiar to you and you have some pointers for me.

As this is a different issue than the topic title says, should I open a new topic or continue this one?

[mon2]

This last batch of issues is common to many models. The sensors cannot be read so the fan spins in turbo mode. The sensors and battery are communicated over the i2c / SMBUS interface.

Carefully measure the voltage to ground of each pin on the battery connector. Checking to see if the sda / scl lines are being shunted to ground.

[jkruns]

Thank you for responding! I will go ahead and measure all the pins on the battery connector (at the office now).

If I understand the schematics correctly, I should get 3.3V on pins 2 and 3, and 3.8V on pin 7, correct?
The sda/scl lines you're referring to, what else can I check besides the J5151 connector?

[mon2]

Another method to test the lines is to remove all power. No battery as well.

Meter in diode mode. Short the meter probes and you should hear a tone beep.

Red meter probe to ground. Black meter probe to point to test.

Measure at the contacts again or at the esd diodes that should be nearby. You can highlight the entire line of parts camped on the same pin using the boardview file.

Post the diode mode measurement which may be more convenient and less risky than a live power on test method.

Do inspect your trackpad connector and cables for the same reason.

[jkruns]

Allright, here's what I measured.




This was with the charger and battery disconnected. The resistance at pin 7 was slightly higher with the battery connected. I included the reference resistance values from openboarddata.org.
Voltages are fluctuating between 0 and 3,25V 3,5mV respectively, about once every 2-3 seconds. It would stay at the peak voltage for 2 seconds and then drop to zero again.

It seems something is trying to ramp up the voltage but failing to keep it there.
Pressing the old control-option-rightshift-poweron combo overrides something (a sensor?) which forces the voltage to stay up and boot the machine.

I also checked all the pins at JT400 (trackpad connector). These pins all seem to have a healthy resistance to ground. The last 8 pins to PPBUS_AON all read .516.



Only thing I can see not being kosher besides the voltage going up and down is the lower resistance to ground on SYS_DETECT_L.
I checked on an identical board which reads .540 at SYS_DETECT_L so it's definitely off.

I tracked SYS_DETECT_L to TP5100, where I get .444 which is pretty close to the reference value.

So SYS_DETECT_L has .176 to ground at the battery connector but on the back of the board at TP5100 it's .444.

[mon2]

We need to sort out the terminology.

A resistance measurement will be reading stated with units of ohms; kilohm; megaohm, etc.

In diode mode, you are checking a voltage drop across the 2 terminals.

So SYS_DETECT_L has .176 to ground at the battery connector but on the back of the board at TP5100 it's .444.

Be sure that in DIODE mode, the red probe is to ground and the black probe is on the point to test. If yes, this implies that you have a trace break between the 2 points being measured.

Confirm it by shorting your meter probe while still in DIODE mode. You will hear a tone beep. Next, one meter probe @ TP5100 for this signal and other meter probe at the battery connector.

You should still hear a tone beep unless there is a break in the PCB trace from these 2 test points.

Do select this signal on the boardview diagram and confirm that this signal is also directly mated with TP5100 - if yes, you have a trace break.

[jkruns]

Thank you for clarifying the terminology, I get confused sometimes.
In diode mode, I always test with red probe to ground, black probe to the point being tested. I think I got this from reading one of your posts a few weeks ago :-)

There does not seem to be a trace break. It's not easy probing two tiny points on either side of the board simulaneously, but there's a clear beep.

It turns out the low voltage drop at SYS_DETECT_L was a red herring. I'm getting .502V now. Same board, same multimeter, same settings but I disconnected all other components and took it out of the top case. I think the first time I measured it was still connected to sound board, touchbar, kb backlight, fan and display. This might have had an impact.

So all the readings from J5151 are fine except the voltage drops. What could cause these?

[mon2]

Locate each and every SMBUS on the board. With no power to the board, meter in diode mode. Measure each such SCL / SDA line in DIODE mode. Searching for a shunted pair of communication lines in this initial review. Some sensor is failing and causing the fan to enter turbo mode. You should be able to run a diagnostic which will offer details on which sensor is failing. This failure can be a smbus / i2c communication fault; truly a bad sensor reading. On the battery area, there is a level translator to shift the 3v3 to a lower pair of voltages (1v8?) - confirm that side of the level shifter is ok. I do not have the schematic up at this time to index the level shifter labels.

[jkruns]

I searched the schematics for SMBUS, which gave me the battery charger support (schematics below)
I carefully measured all the components in this circuit and compared these values against the reference from OBD.



All but one of the components were well within spec. The thing that was off was the CHGR_EN_MVR_A which whould read OL but instead I measured 2.032V.
R5342 and D5340 both look fine visually, as does the board in this area. This was also not an area of the board where the liquid damage occurred.






Next thing on the list was searching for level shifters with 3.3V input and two 1.8V outputs.
There's a pair of those: the PARROT 0 I2C/RESET LEVEL SHIFTERS and PARROT 1 I2C/RESET LEVEL SHIFTERS.
I checked both and all the values look fine (only PARROT 0 included in the table below).







I couldn't find any other SMBUS references.
Regarding the level shifters, did I test the ones you referred to?

[jkruns]

This may be a dumb question, but what's the story with the contact points on the board where the schematics say there should be a resistor but there isn't any visible smd component at that location?
Case in point R5155 which should be a 10K resistor with a 402 footprint, but there isn't any.

I'm trying to figure out why the battery isn't charging, but so far every measurement seems reasonably within spec. I've looked into the Battery logic connector schematics and measured each component several times. The mosfet at Q5155 sems to play an important role here.
To test this mosfet, I checked the resistance of the gate (SYS_DETECT) to the drain (SYS_DETECT_L) and I got 6.3MOhm. My other boards showed 3.4MOhm, but this at least tells me the gate and drain are not shorted.

Am I reading the schematics correctly when I say that when the battery and power adapter are connected, the the mosfet at Q5155 should allow 3.8V through to pin 7 on the battery connector J5151?

[mon2]

The referenced resistor is a "NO STUFF" component. It was just a 'CYA' as we call them here = 'cover your a**' and placed for R&D / early testing phase of the PCB layout. In live production, not required.




Can you share the I2C line voltages to ground of the battery connector again with the power adapter connected?

Have you tested with another known good battery? Or does the OS properly report the specs of this battery ? Can you share a screen grab of that screen?

Do you see the # of charge cycles, serial #, etc. of the battery? If yes, then the I2C lines are working ok and the fault is elsewhere.

[jkruns]

The referenced resistor is a "NO STUFF" component. It was just a 'CYA' as we call them here = 'cover your a**' and placed for R&D / early testing phase of the PCB layout. In live production, not required.

Ah. Thanks for explaining NOSTUFF. At first I thought I might have knocked a resister off the board, until I saw the same omission on the other boards 😄

Can you share the I2C line voltages to ground of the battery connector again with the power adapter connected?

The I2C line voltages on both pins 2 and 3 stay at 3.22V for a few seconds, then briefly dropping down to as low as 2.45V for about half a second. I've included a little clip of the multimeter readout.

Have you tested with another known good battery? Or does the OS properly report the specs of this battery ? Can you share a screen grab of that screen?
Do you see the # of charge cycles, serial #, etc. of the battery? If yes, then the I2C lines are working ok and the fault is elsewhere.

As far as I know, all four batteries I've tested with so far are good. At least they were before something else broke in the laptop they were in (screen / mainboard mostly).
The OS does indeed properly display the battery specs, complete with cycle count (161 in the case of the original battery that was attached to this main board). It just says "service recommended". Please refer to the screenshots in this post.

If I had just this one laptop battery I would probably just take my chances and order a new one. But what are the chances of four relatively low mileage batteries all failing to charge at once?

[mon2]

Battery and the I2C battery leg are not the fault since you can extract the vitals from the battery's bms board.

Need to review the current sense leg of the battery charge circuit. This is by the ISL charger ic and need to measure the start to finish resistance. This is to confirm the current sense loop is not out of spec. Do this with no power.

Also each linked mosfet should be inspected to be sure they are not leaking. This can be done in resistance mode.

[jkruns]

Need to review the current sense leg of the battery charge circuit. This is by the ISL charger ic and need to measure the start to finish resistance

I assume the ISL charger IC is U5200, correct? If so, what points or lines should I regard as the start and finish? Start at PPDCIN_USBC_AON? What should be the finish? PPVBAT_AON?

[mon2]

See attached. Remove all power. Meter in the lowest resistance scale. Measure the resistance with a meter lead on each of the referenced arrows. We are measuring the total path resistance to confirm the sum of the resistance is close / equal to the schematic values. If the resistance is different, then the charger IC (ISL9240) will sense this and shut off the charging mosfet.

[jkruns]

I will of course do this asap, but I also really want to understand the logic behind this.

How did you deduce from the schematics capacitor C5260 is where you can measure resistance of the "current sense leg"?

And what should be the total resistance reference value? If I had to guess it would be the sum of the three resistors R5261, R5260, R5262, so 2.005Ohm?

[mon2]

How did you deduce from the schematics capacitor C5260 is where you can measure resistance of the "current sense leg"?

we really want to measure at A4 - B4 balls on the charger IC but this is not possible due to these balls are hidden underneath the wlcsp package. This capacitor is the closest part which we can measure.

Yes on the total path resistance.

The design engineers at Apple expect this resistance and this ISL chip is measuring the voltage drop across the tiny current sense resistor that is in milli-ohms. The voltage drop is used to gauge the load which is the battery. If the resistance is different or the path is broken then the measurement will be different than what was expected and charging will halt. This is the function of the CSOP and CSON balls.

[jkruns]

This is the function of the CSOP and CSON balls.

Makes sense, but how could I have deduced this from the schematics?
There's a list of Power validation test points included in the schematics, but you would have to know what CSO_N and CSO_P stand for or what they do. How did you figure that out?

[jkruns]

Resistance across C5260 is 2.91Ohm. The other boards read 2.74 / 2.72 / 2.86 respectively.
Unless the tolerances are really tight, this should be ok, right?