820-00840 no SYSCLK_CLK12M_SMC

[melvinvdb]

Hi all,

I'm repairing a water damage 820-00840 here. Visible liquid damage is around u3900, u8400 and u7650. Has been cleaned.
So situation is as follow:
-PPDCIN_G3H = 5.2v
-PP3V3_G3H = 3.4v

Started by replacing both CD3215 (might not have been needed after all):
- PP20V_USBC_XA_VBUS = 3.4v
- PP3V3_UPC_XA_LDO = 3.3v
- PP1V8_UPC_XA_LDOA = 1.8v
- PP1V8_UPC_XA_LDOD = 1.8v
- PP1V1_UPC_XA_LDO_BMC = 1.1v
Same with XB.
Also I see activity on UPC_XA_UART_RX, UPC_XA_UART_TX and TBT_X_SPI_MISO.
This indicates that the CD3215s are ok to me.

I had a short on PP3V3_G3H and u1900 (SLG3AP3444) got hot.
Replaced u1900 from a donor board but SYSCLK_CLK12M_SMC is still missing.
I think the schematics say that SMC_CLK12M_EN should be high to enable the clock for the SMC.
The SMC is needed to communicate with i2c to the CD3215s right?
SMC_CLK12M_EN is low and is generated from the SMC.

So SMC u5000:
- PP3V3_S5_SMC = 3.4v
- BUF_SMC_RESET_L = 3.4v
- SMC_BC_ACOK = 3.4v
- SMC_CBC_ON (not sure if needed I don't have a working board) = 0v

So questions are:
SMC clock needs to work to communicate with the charger to get 20v right?
Do you guys have any idea if the SMC is at fault here or do I need to measure more?
It could be that the old hot u1900 had blown the SMC SMC_CLK12M_EN pin.

Thanks in advance

 

[melvinvdb]

Anyone?
I've reflowed the SMC but no difference.
SMC_CLK12M_EN isn't going high so the SMC won't get a clock signal.
I do not know what the requirements are for the SMC to enable SMC_CLK12M_EN.
SMC_RESET_L is high.

 

[2informaticos]

Do you get 24MHz oscillation at Y1900?

"-PPDCIN_G3H = 5.2v
- PP20V_USBC_XA_VBUS = 3.4v"
Can you confirm that???
First voltage is generated from the second one...

 

[melvinvdb]

Sorry made a little mistake in the post:
-PPDCIN_G3H = 5.2v
-PP20V_USBC_XA_VBUS = 5.2v

I do not have oscillation at Y1900.
However, I do have a nice SYSCLK_CLK32K_PCH going to the PCH.
I do not have SMC_CLK32K from the PCH to the SMC...

 

[melvinvdb]

Well I've checked with a working 820-3476 to check some clock signals.
SMC doesn't need the 32khz clock for the green light so probably also not for the 20v line.
SMC however does need the 12mhz clock.

Not sure if needed but S5_PWRGD is NOT present.
This is because PP3V3_S5 is only about 1.2v. Should PP3V3_S5 be available for the charger to switch to 20v is the question?

 

[2informaticos]

I suppose Y1900 should have 24MHz always.
OE_12M input should enable x1/2 divider only.
Check R1900 and traces.
Replace C1907/08, Y1900 and U1900 (again, just in case).

 

[JohnB8812]

You don't have 20 volts on DC in that is your first problem. If PP3v3_G3H is present, you likely have an issue with one of the CD3215 chips. Do a diode mode reading of the LDO lines by both CD3215s to see if either measures low. My trick is usually to inject 3.3 volts into 3v3_G3H and monitor for current draw. Usually, one of the CD3215s causes a slight amperage draw.

 

[melvinvdb]

Checked all traces around y1900, resistors and caps. All seems fine.
u1900 generates the 32khz from itself somehow. The 24mhz clock is started when enabled through one of the VIOE lines (and probably SMC_CLK12M_EN) I think.

Measured both CD3215 chips:
- PP20V_USBC_XA_VBUS = .345
- PP3V3_UPC_XA_LDO = .494
- PP1V8_UPC_XA_LDOA = .512
- PP1V8_UPC_XA_LDOD = .474
- PP1V1_UPC_XA_LDO_BMC = .496

- PP20V_USBC_XB_VBUS = .345
- PP3V3_UPC_XB_LDO = .495
- PP1V8_UPC_XB_LDOA = .499
- PP1V8_UPC_XB_LDOD = .467
- PP1V1_UPC_XB_LDO_BMC = .484

Does injecting voltage have any advantage if the line works fine from the charger?

 

[2informaticos]

32KHz is square wave, generated internally by U1900; no external crystal needed.
If you have working similar board, check if 24MHz oscillation is present on Y1900 when board is off.

 

[melvinvdb]

I just checked with a 3476 board (with a magsafe2) that the 24mhz clock starts after power is applied to PPDCIN_G3H.
So the 24MHz crystal is not interesting anymore.

Amazingly so isn't the 32KHz clock.
What I did:
- Probe 1 (yellow) on SMC_CLK32K
- Probe 2 on SYS_ONEWIRE


SMC_CLK32K starts about 600ms after SYS_ONEWIRE communication is done.

Than to go even further:
- Probe 1 on SMBUS_SMC_5_G3_SCL
- Probe 2 on S5_PWRGD
I'm looking to find what enables the SMC to start communicating with an bus.

Why SMBUS_SMC_5_G3_SCL? Because I don't have a SMBUS_SMC_4_G3_SCL (that communicates with the CD3215) on the 3476 so I took SMBUS_SMC_5_G3_SCL that's available on both the boards.

So when S5_PWRGD is present SMBUS_SMC_5_G3_SCL starts immediately (even when no clock is available yet).
I've also checked that SMBUS_SMC_5_G3_SCL and SYS_ONEWIRE starts at the same time.

This concludes the following:
- The SMC doesn't need ANY clock source for it to work (probably also for communicating with the CD3215s)
- Maybe S5_PWRGD is needed but need to check more

 

[melvinvdb]

When looking at the publicly available TM4C123x this makes totally sense.
http://embedded-lab.com/blog/tiva-c-clock-system/
The TM4C123 contains a Precision Internal Oscillator (PIOSC) so yeah...
32khz is for MCU hibernation and the external for some pheriperals inside the MCU.
Going to look what might be needed for the SMC to start communication. It might be just PP3V3_S5 is needed but I do not know.

 

[melvinvdb]

Well I've replaced both CD3215s again. Same issue. Very frustrating.
I know for sure the CD3215s communicate with the ROM chip so that's fine. Checked all traces all are OK.

We do need a working SMC right to communicate with the charger on these usb-c macbooks? Louis doesn't say anything about that in his vids.
To him it's all about PP3V3_G3H and the two CD3215. These are fine.
The CD3215s pull SMC_USBC_INT_L low after a very short time so they say an interrupt is available.
The SMBUS_SMC_4_G3_SCL/SDA both go high with a pullup resistor but there is no communication on that line.

I don't have a working usb-c board to check with but I'm interested in the following:
- Is there communication on the SMBUS_SMC_4_G3_SCL/SDA before 20v is reached? This verifies a working SMC is required.
- Is PP3V3_S5 present before 20v is reached? This verifies that S5_PWRGD needs to be present before the SMC starts to live. I don't have this line working.

 

[2informaticos]

"PP3V3_S5 is only about 1.2v."
Do you still have 1.2V on L7690?
Post some voltages for U7650; pins 23, 12, 13, 22, 29, 21.

 

[melvinvdb]

There was corrosion around U7650.
pin 22 (VREG3) trace was broken due to corrosion.
After fixing VREG3 I now get 0v on PP3V3_S5 and P3V3S5_EN is low.
- pin 23 is 0v because PPBUS_G3H is 0v
- pin 12 0v
- pin 13 0v
- pin 22 0v
- pin 29 0v - pin 21 0v

 

[2informaticos]

Strange to get any voltage at 3V3_S5 (even low), if no PPBUS_G3H present.
Post resistance to ground (diode mode) for PPBUS_G3H.

 

[melvinvdb]

Yeah thats not possible. 3V3_S5 had a low voltage. Now it doesn't so doesn't PPBUS_G3H.
PPBUS_G3H diode mode when doing the red wire on ground:
- 0.422

Should PPBUS_G3H be at 5v from PPDCIN_G3H when there is no 20v?

 

[2informaticos]

PPBUS_G3H could be even 13V when PPDCIN_G3H is 5.2V.
But SMC decides that, in base of power supply detected.
It needs to talk with the power device attached to USB-C port.
Seems that it can't in your case.

 

[melvinvdb]

Even without battery? I thought u7000 is a buck converter that can't do boost or can it?
The SMC is already reflowed so either the SMC is dead or SMC is missing something I guess (like maybe S5_PWRGD).
I think the best way for me would be to buy a working board and compare. Than I can always use that board to compare if no 20v is given.

 

[2informaticos]

U7000 can work as buck-converter (with Q7030) when receives 20V at R7020.
But it can work as boost-converter too (with Q7040) from 5V at R7020.
High-side MOSFET of "unused" Q7030/40 will stay always ON (short) and low-side one in OFF (open) state.
Only one of Q7030/40 works in PWM mode.
To enable fast battery charging, 20V required for buck-converter mode.

I don't have similar board to play with now, but I'm pending for more tests when available.
Recently got one A1534/00045 where I can confirm 8.6V at PPBUS_G3H, even 3V3 and 5V at the coils; with only 5.2V from charger (no battery connected).

 

[melvinvdb]

Interesting.
But u7000 is enabled from SMC I think. Unless it always tries to add voltage to PPBUS in that case u7000 is faulty.
So two scenarios:
- u7000 always add voltage to PPBUS which results in U7650 maybe enabling P3V3S5 which results in S5_PWRGD which enables SMC.
- u7000 waiting for SMC which just simply doesn't start and doesn't require S5_PWRGD.
It al comes back to S5_PWRGD. If that is not needed for the SMC to start communicating on any i2c line like CD3215 or U7000 than the SMC is bad.