Legion Y540-17IRH-PG0 troubleshooting

[suho]

Hello everyone,

I have a Legion Y540-17IRH-PG0 with NM-C541 Mainboard with the following symptoms.

After pressing the Power button ...

• The fans spin very briefly and then turn off
• The keyboard backlight turns on for 2-3 seconds
• The power button and the side LED1 stay on for roughly 15 seconds and then turn off

I cleared CMOS which did not help. Charging seems to work just fine, so battery management is not the problem. I checked the power rails for shorts, seems fine to me. Only the NVVDD rail is fairly low resistance with 0.65 Ohms. However this can be normal for GPUs afaik.

I then read the BIOS chip and used MEAnalyzer to check. It gave me some checksum errors and under "File System State" it says "Error". Ok, I thought then maybe this is the problem and I proceeded with clearing the ME region as was described on this forum and reflashed it. In the picture attached you can see the original and the cleared image file. Unfortunately this did not work either. So I downloaded a new BIOS from Lenovo (BHCN45WW) and extracted the firmware using Insyde IFD Extract from https://github.com/platomav/BIOSUtilities

I then copied the DMI data (632000 - 633FFF) from the original to the downloaded image and flashed it. Again unfortunately it did not work. Maybe the problem is not just the BIOS?
From the Lenovo BIOS update other files were also extracted like Certificate and Platform.ini etc. Maybe I have done something wrong? I just assumed it is the contents of the Flash chip cause the file size of the extracted .bin file matched. ME Analyizer looked fine and also Intel Image Tool did not report errors when loading it.

Does anyone have an idea what the problem could be instead?

Thanks for your help.

[mcplslg123]

Doesnt seems like bios issue going by your efforts so far. Link schematic/bdv if available.

Need to check voltage and resistance to GND readings on all coils after presssing power button.

[suho]

Thanks for the suggestion, I checked all core voltages when switched on. Everything seems fine except for the rail named VCCGFXCORE in the schematic, which is at a low 0.62 mV. Seems to be dedicated to the internal GPU of the CPU. The way I read the schematic it should be available at the same time as the CPU core voltage cause the buck converter FETs share the same SYNC pin. So either the PWM signal from the controller or the MOSFET is bad. I can check the PWM with a scope but my bet is on the MOSFET. Or is there any other reason why the VCCGFXCORE should be off at the start? The voltage to the dedicated GPU is on and seems fine right from the beginning.

[suho]

I have checked the PWM on the MOSFET (MP86941), its at half of the supply voltage which according to a datasheet means diode emulation mode. Since the PWM pin is pulled to half of the supply in the FET internally, it could indicate a broken trace of from the controller or the controller is not outputting anything, not sure what to make of this. The controller is controlling 6 rails and 5 of them are working. I cant find any datasheet for the controller unfortunately. It is a MP2979A. Does anyone have a datasheet?

[suho]

I was looking at the datasheet of a similar VR controller and I now see that there is a serial bus between CPU and VR controller, which makes sense for modern systems.
Anyway in the datasheet it says: "For rails where the boot voltage is set to 0, the PWM of the rail remains in tri-state until a valid SVID voltage is received."

Can someone confirm whether it is normal behavior for intel CPUs that the iGPU power is switched on at later stage during the startup process?
I mean there is another deicated GPU so it might make sense?
Because then I need to look somewhere else for the problem.

[suho]

I have checked all rail Voltages now, including some auxiliary ones not present in this diagram.

Everything seems to be in order except for the iGPU core voltage which is not present during startup. However, I guess this could be normal behavior.

I have also checked the clock signal from the BIOS chip and can confirm, that something is happening, i.e. data is being transferred. Does anyone know under what conditions the EC controller determines that something is amiss and switches everything off again after 15 seconds? Is there some JTAG like debugging that I can do?

[mcplslg123]

VCCGFXCORE is irrevalent as it'll rise under load. If you have a DSO then check by probing GFXcore coil and you'll see a slight pulse comes for a moment and then goes away. If this is so,then nothing wrong here.
Btw, DRAMRST# is present?

[suho]

I checked DRAMRST#. At least I think I did, cause I had to aquire a boardview to find a spot where to sample the signal. However I could not find a boardview for the exact same PCB I have so I used another from the same lineup of laptops which looked very similar.

DRAMRST# is pullled high through a resistor and when everything is initialized it should be pulled low by the PCH I assume? I checked with a DSO, there are some attempts (I guess) to initialize the RAM so I can see some spikes of roughly 10 µs length where it is pulled low but then it goes high again. I don't think that is how it should be right?

Also I used a Raspberry Pi pico as a logic analyzer (https://github.com/dotcypress/ula) to read the LPC Bus. I am getting the clock signal just fine but nothing is happening on the other lines. Was hoping to get some POST codes. I guess that only happens when the BIOS starts to execute?

[suho]

Once I plug in the AC, I see some traffic on the SPI_CLK. I assume this is coming from the EC as it is reading its programming from the BIOS chip. EC_RSMRST# goes HI almost immediately after the AC is plugged in, so the programming of the BIOS seems to be fine.

Once I press the power button, DRAMRST# goes high but it shows these pull down spikes every 1.7 ms which have a width of around 3 µs. Does anyone have an idea why this might be the case?

[mcplslg123]

DRAMRST# is ok as per DSO pic.