A few hours ago I started hearing a beeping noise coming from my office. It was the disconnect/reconnect sound. Upon further inspection, I noticed that my 13 (Ultra 165H) was cycling between charging and discharging constantly. dmesg is filled with ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-70) and upon further inspection using the framework_tools.efi, I notice that it fails to probe the EC version.
Thought this MOSFET failure was only a 11th gen thing…but I guess any component could go wrong, regardless of mainboard generation. Hope we won’t see more of this.
And this is only one case of this issue in a newer mainboard. The MOSFET itself may not even be the issue, if a failure or glitch happens elsewhere which causes improper control of the MOSFETs, they can then overheat.
I was asking more from a point of view of trying to understand what might be causing the mosfet fails.
Mosfet fail for a number of reasons:
overvoltage
overcurrent
switching transition rate.
oscillations in the gate part of the circuit causing it to spend too long in the middle(linear region), between on/off
I am thinking that some psu interaction, transition might be causing the problem.
For example, maybe the laptop is thinking it is requesting 5V, but due to a bug, the psu thinks it asked for 36V.
But that being said, there should be protection circuit around the mosfet to protect it, but we don’t have the circuit diagram to understand what weakness the circuit might have.
…that we know of on the forum…at this point. Hope it’s only a glitch in the matrix.
Agree. It could be upsteam components, or combination of. Framework would care how / why it happened. Customers, not so much, the laptop as a whole needs to be working. 99.9xxx% reliability of each component comes into play for the entire unit. I do wonder though if we are seeing more or less MOSFET failure (direct and indirect) compare to other components. e.g. We’ve seen fan failure, fingerprint reader failure, keys / keyboard, touchpad…etc. Any component could go wrong, regardless of brand. Don’t think we, on the outside, have sufficient transparency to know if FL13 is getting more or less reliable through the generations.
I sent these pictures to support immediately on Wednesday, expecting another prompt response, but as of today (Friday) I still haven’t heard anything back. Weird.
Radio silence after what was very punctual service…hmmm
I really can’t be without my machine any longer so I just transferred the heatsink assembly from the defective board to the new board and cleaned/reapplied the TIM, which is something I’ve wanted to do for a while anyway.
But I am still concerned that there is something funky going on with this new board. But maybe I’m just being overly sensitive / paranoid.
For starters, I upgraded the BIOS to 3.04 first thing and ended up with one PD controller on v0.0.8 and the other on v0.0.A. I had to install Windows and use the Windows BIOS updater in order to nudge the remaining PD controller to upgrade. The UEFI updater (which I originally used) simply refuses to reinstall the update.
The Failed to find PlatformFamily bug from framework_tool.efi --versions is still present on this new board, so likely just a EC bug. I’ll report on GitHub soon.
–
The other issues are likely a combination of bios and/or os/kernel bugs that I just haven’t noticed until now. I will be posting on the 3.04 BIOS thread too:
okay, I’ve tried really hard to be supportive and understanding but this is taking a strange turn.
Support actually asked me to carefully bend back the heatsink fins. I will produce the receipts if requested. If this is the direction you want me to follow fine, send me a new heatsink then.
Umm, no thanks. I will be sending the defective board and the damaged heatsink back to your OEM repair shop ( PanurgyOEM ) that is paid to perform these repairs. I’ve already swapped the heatsink from my old board to the new one.
You don’t want an invoice from me for my time. I’m too expensive.
When I got the replacement board last week, I made the executive decision to just swap the heatsinks. I didn’t ask for permission. In fact, I had already shipped the defective board back with the damaged heatsink by the time support finally asked that I just “bend the fins back”.
Like I mentioned before, support was very punctual at the onset of this ticket (I was very impressed), but once the replacement board was shipped, the round trip response time went from 3-4 hours to 1-2 days. I honestly never thought they would have suggested that as a fix. I don’t have time for that nor do I have time to wait around for a response. This is my primary work machine. I was already a bit peeved at swapping the heatsinks around but justified it because of the opportunity to clean and apply some quality TIM.
The correct response (imo) from support should have been one or some combination of the following:
“Swap the heatsinks between the two boards” ← this is what I ended up doing
“We will send you a new heatsink”
“We will send you a new board”
I do believe there is some good, constructive feedback to glean from this situation.
