When my USB Tester is plugged into a Framework port, it reports 5.02V - 5.03V if nothing is plugged into the tester. When I first plug the Seagate drive in, the voltage drops down to 4.96V at the lowest, though I saw it drop down all the way to 4.93V when running a CrystalDiskMark test. When the drive is idling the voltage is usually between 4.98V and 5.02V… ooo… I just saw it surpise disconnect while doing this measurement and when I glanced at the voltage, it was 4.97V.
When plugged into the powered hub, the tester reads 5.18V - 5.19V with nothing plugged into it. When I plug the drive in, the tester drops as low as 5.13V. Idling, the drive gets back up to 5.18V.
When plugged into my MacBook, the tester reads 5.07V with nothing plugged into it. When I plug the drive in, it drops down to as low as 4.97V. It idles at 5.04V.
I’ve noticed in my current round of testing that I can easily reproduce the disconnect error. This is a lucky break as the error itself can be flaky in reproducing.
If I plug my Seagate drive into the Framework and get it to connect as USB 3.0, wait a minute or two for the drive’s light to go off, and then try to explore the drive, Windows brings up an error message: “E:\ is not accessible. A device which does not exist was specified.”
If I plug the drive into the powered hub and wait for the light to turn off and then go to explore the drive, there is a bit of a pause while the drive turns on and then explorer comes up and I can browse the files.
If I plug the drive in halfway into the Framework USB-A module which forces it to connect as USB 2 (then plug in all the way after it shows up), and wait for the light to turn off, then explore the drive, there’s a pause but then I’m able to explore the drive.
I ran these experiments both with and without the USB Tester. With the USB Tester I was able to measure:
USB-3 connected to Framework: Idle 5.02V 0.039A.
Exploring: Voltage drops to 4.95V, Amps increase to 0.750A at ~4 seconds.
Drive disconnects.
USB-3 connected to Powered Hub: Idle 5.18V 0.038A.
Exploring: Voltage drops to 5.08V, Amps increase to 0.752A at ~2 seconds
Drive stays connected.
USB-2 connected to Framework: Idle 5.02V 0.037A
Exploring: Voltage drops to 4.96V, Amps increase to 0.716A at ~2 seconds
Drive stays connected.
I made videos of each of these tests and it does seem like the biggest difference is that the USB-3 connection from the Framework is slower to provide amps.
Edit: Actually, I watched more closely and noticed that the Windows error message comes up instantly - as soon as I explore the device. So somewhere lower down, Windows has already decided that the drive is disconnected when it goes into the lower power state or I mean it doesn’t give it very much time to spin up. However, again, this is only when connected via USB-3 to a Framework port. When connected via USB-2 to the Framework or USB-3 to the hub (which is connected to the framework), the drive can go back and forth between the low power state without problems.
Usb-3 operates at frequencies high enough to interfere with wifi.
Here, the additional plug can bring its own issues (should not happen, but…).
The C=C module has a plastic topside, the C=A module a metal one connected to ground: C is not shielded where A is.
You could try to eliminate the difference in shielding between A and C. Insert a very thin metal leaf (tin plate cut from a soda can, for example) between C module and laptop, and make sure it is connected to the metal bottom (connects to ground). Then test again.
Just omitting the module would have been the easiest way to rule out this suspect once and for all possible mechanisms.
To dig deeper, lab equipment and more competence than I have would be needed.
The voltage drop could be so brief that you can’t catch it with the tester (too inert, too low sample rate – dunno how it works internally), but sharp enough to make the devices disconnect. (*)
The devices themselves could be finicky.
The laptop could be capricious.
Some sharp field change couples in (lack of shielding).
Luckily I have a FW ethernet expansion card. I believe this issue still occurs while using the card but I will get around to testing again. I’ll make sure to turn wifi off so there isn’t any traffic at all even when connected over ethernet.
I think that if the interference was this much of an issue I would be noticing very bad performance in comparison to using the drive over USB-A. In reality I have been getting insane speeds over the USB-C cards (nearing the theoretical 10gbps limit of my SSD enclosure).
@Nikola_Dekovski Have you tried increasing the time on the “Turn off hard disk after” advanced power option? You might need to make the option visible like this:
@brianshmrian I ran some tests just now and no, this doesn’t have an effect.
Unfortunately even if it did it still would be a bad and illogical solution, as this issue doesn’t occur over the USB-A connection.
To add even more salt to the injury it works perfectly fine on a samsung phone and doesn’t work at all on a samsung tablet.
What’s infuriating is that just today I had the opportunity to test a new enclosure by the same company, which isn’t the same model (the chip inside appears to be the same - the RTL 9210) and yet it works perfectly fine - no problems or issues at all!
Yeah, it’s frustrating. I wish I knew a better way to debug the problem to get more info since it’s pretty reproducible.
I was hopeful that since I sent my old mainboard back to Framework, they’d be able to reproduce it using that, but either they didn’t try using the board or they couldn’t reproduce the problem on that board.
I would actually be curious to have a conversation with the team trying to reproduce the problem. This is what support told me about a week ago:
Thank you for your ongoing patience this case, I wanted to provide you with an update. Our team has been unable to reproduce this exact scenario despite significant effort to do so.
Our Engineering team is currently working on a forthcoming BIOS update for 11th Gen Intel Core which we expect to have a beta version we can prove you with soon, as this release contains some errata for CSME that may help mitigate some USB disconnecting edge cases. I will update you as soon as I have further news on this.
I did have one idea where I could factory reset the computer, make sure the problem still reproduces, then offer to trade Framework my laptop for one on which they can’t reproduce the problem. That way the problem is fixed for me and they have a laptop that they can use to investigate. Win-win!
Another idea would be to take my laptop down to their offices sometime. Of course I don’t live nearby. All of this thinking can get out of hand especially because my workaround is fine. That’s why I said earlier "I slowly experiment with different ideas as the mood hits in order to gather more info (while trying not to spend too much time looking into it.) " It’s easy to get obsessed with this thing like I’m on the hunt for the Zodiac killer or something
I used usb debug tracing to get a couple more event log errors when reproducing the disconnect: USB-USBXHCI error 34 and USB-USBHUB3 error 123.
According to my tech support assistant Bing Chat:
The event ID 34 means that the USB 3.0 driver (USBXHCI.sys) failed to start a device on a port. The completion code 19 means that there was a transaction error on the port. This can happen if the device or the cable is defective, or if there is interference or noise on the bus.
And about error 123 Bing says:
Based on the information, it looks like you have encountered a port change request failure on port 3 of your USB 3.0 hub. This means that the hub driver failed to reset the port after a device was connected or disconnected. This can cause the device to become unusable or unrecognized by the system.
I’ve sometimes thought there was an EMI interference possibility given how weird the problem is (and the fact that there were EMI shielding problems in early framework models). Once again, according to my IT guy Bing Chat:
Noise on the bus can cause error 34 because it interferes with the communication between the USB controller and the device on the port. Noise can be generated by various sources, such as coil whine, dirty USB power, damaged USB port, or incompatible USB cable. Noise can affect the signal integrity and cause errors or data loss during the USB transactions. A transaction error means that the USB controller detected an error in the data packet or did not receive an expected response from the device. This can prevent the device from starting or functioning properly on the port.
@brianshmrian
Hopefully something comes out from all the efforts you are making.
Later this week I plan on trying to get my SSD enclosure replaces by the vendor just in case the RTL chip is faulty and that is what was causing the issues.
