820-00840 no SYSCLK_CLK12M_SMC

[2informaticos]

SMC is the master, the one which set PPBUS_G3H level.
So communication through corresponding I2C bus is required.

Remove U5274/R5275 (as per case) and check if any voltage appears at PPBUS_G3H.

 

[melvinvdb]

No difference.
SMC_RST_IN is also around 90k.
SMC_RST_IN stays LOW which seems fine..

 

[2informaticos]

Yeah, on old boards is active low; its name ends in _L.
ISL6259 will deliver 12.25V (3 cells battery case) with 0V at reset pin (reset enabled).
In such case no communication is possible through I2C with SMC.
You can force now 3V at ISL9239 reset pin (SMC_RST_IN); it will enable reset in this case.
Don't forget to isolate SMC_RST_IN for the rest of board.
U7000 should enable reset for SMC too (0V at SMC_RESET_L) and you can check if some voltage appears at PPBUS_G3H.
I don't know untill which point has similar behaviour with old boards...

 

[melvinvdb]

Well nothing interesting is connected to SMC_RST_IN or SMC_LSOC_RST so i've applied 3v to them (no keyboard connected).
Result is SMC_RST_IN low, SMC_RESET_L low and BUF_SMC_RESET_L low.
No voltage at PPBUS_G3H.

Very interesting things happen though when I disconnect the 3v.
SMC_RESET_L gets high again (3.41v) but BUF_SMC_RESET_L gets to only 1v.
After disconnecting charger and reconnecting same thing happens. Than waited some time reconnect charger and BUF_SMC_RESET_L is 3.41v again.
I do have U8510 (SLG4AP4998).
I though you may have found the issue but after waiting and reconnecting charger it's 3.41v again. So either the SMC is doeing weird things or U8510 may be bad.

 

[2informaticos]

Discard U8510 first.

"Result is SMC_RST_IN low"
You are injecting 3V there, no?

 

[melvinvdb]

Sorry damn I'm making mistakes in documenting it here.
SMC_RST_IN high to 3v
SMC_RESET_L than goes low.
BUF_SMC_RESET_L also goes low.

When SMC_RST_IN power is removed:
SMC_RESET_L goes to 3v
BUF_SMC_RESET_L sometimes stops at 1v

What do you mean with discard U8510? What does it do? In the schematics there is a bypass version which just has a 0 ohm resistor between SMC_RESET_L and BUF_SMC_RESET_L.

 

[2informaticos]

Change U8510, if possible.
Or try the bypass at least (chip removed); just to see what happens with PPBUS_G3H.

 

[melvinvdb]

Ok I've removed U8510 and replaced it with a bypass resistor just for the SMC_RESET circuit. When the 20v works I'll place a u8510 from a donor board.
Anyway the 1v issue is gone. Still no difference on the other rails. Still nothing on PPBUS_G3H.

 

[2informaticos]

Can you change U7000?

 

[melvinvdb]

I don't have them available but can order them. Will take two week though.
So at this point I think that would be the best option.
Also If that doesn't work I'm thinking of replacing the SMC.
I have a china donor board with the same 820-00840.
Also on ebay there are SMC chips for sale. TM4EA23IH6ZXRI which matches exactly.
Unsure if that might be an option.
The serial number and manufacturing date are burned in the SMC right? So changing SMC would change serial number?

 

[2informaticos]

New SMC is useless; must be removed from donor board, same model...

We suspect U7000 and/or SMC, assuming good USB-C communication; cross the fingers.
Can you detect any activity (with o-scope) at UART lines of USB-C controllers?
Also look at any data lines between them and SMC.

 

[melvinvdb]

I'm not at location at the moment so I can't double check but I've previous measured the following:
- On UART TX line was activity
- On UART RX line was activity (so they both communicate. Was unable to see at what baud rate though)
- On the SPI lines to the ROM chip was also activity

Will verify when I'm at home.
i2c lines between SMC and CD3215 are not there. They're just high the entire time.
Haven't verified any lines between charger and CD3215 because I need to remove the metal cap around the USB-C controller which I haven't done yet.

 

[melvinvdb]

So I've done some digging.

UART:

1.2us for one bit means a UART baud rate of 833333. High but not impossible. This would make sense because connected to my computer I was getting different data transfers on every baudrate. So 833333 seems possible.


Transfers are send as pairs with some fixed delay in between.


Zoomed out.


Then you can see that there are some long delays between each 'packet'. A total of 10 are send when power is applied. This is the same for TX and RX.

Then SPI:

This is the CLK signal. As you can see the period is 42ns which relates to a SPI clock speed of 23.81MHz. At first I thought that's impossible that's really high.
Than a quote from the SPI ROM chip (W25Q80DVUXIE):
"The W25Q80DV/DL (8M-bit) Serial Flash memory provides a storage solution for systems with limited
space, pins and power. The 25Q series offers flexibility and performance well beyond ordinary Serial
Flash devices. They are ideal for code shadowing to RAM, executing code directly from Dual/Quad
SPI (XIP) and storing voice, text and data. The W25Q80DV operates on a single 2.7V to 3.6V and the
W25Q80DL operateds on a single 2.3V to 3.6V power supply with current consumption as low as 1?A
for power-down."

"The W25Q80DV supports the standard Serial Peripheral Interface (SPI), and a high performance
Dual/Quad output as well as Dual/Quad I/O SPI: Serial Clock, Chip Select, Serial Data I/O0 (DI), I/O1
(DO), I/O2 (/WP), and I/O3 (/HOLD). SPI clock frequencies of up to 104MHz are supported allowing
equivalent clock rates of 208MHz (104MHz x 2) for Dual I/O and 416MHz (104MHz x 4) for Quad I/O
when using the Fast Read Dual/Quad I/O instructions."
So the 23.81MHz now seems pretty realistic.

The SPI ROM size is 8mbit. With a speed of 23.81mbit/s that would explain the very short data transfer on power on. It's really fast.
I'm guessing the entire firmware is in the ROM and is transferred through UART to the other CD3215. There is always one CD3215 connected to the ROM and the other is connected through UART.
When 4 CD3215s are on logic board then there are two ROMS.

Changing CD3215C to CD3215B may be possible when also changing ROM. This may only be valid when the I2C communication with the SMC is the same with the B and C revisions.

Anyway SPI and UART definitely work
USB-C communication still unsure.

 

[2informaticos]

CD3215 chips boot in master/slave pairs.
The second one (slave) boots from UART lines of first one (master).

These new boards require lot of work to collect necessary information for repairs.
I appreciate the time you take on this one.
Should be good to check an working board and see what happens with PPBUS_G3H when SMC_RST_IN is forced high.
You can see then if U7000 requires communication with SMC, in order to generate PPBUS_G3H.