I just had an update 2 after the update 1, have a look!
Btw, what phone do you have, if you don’t mind me asking?
I found my Note 20 Ultra unable to recognize the Sabrent EC-SNVE on both the original firmware and latest firmware. I don’t know if the protocol used by this enclosure simply isn’t supported on Android 13 (or the Note 20 Ultra hardware).
Very interesting and very strange, so it renegotiated to 10Gbps, and there was no indication that it disconnected and reconnected, like the classic Windows device disconnect/reconnect sound, or any notifications?
Edit: I will also see if I can if I can reproduce that behavior
Sure thing, ask away 
I have a Google Pixel 5 (Android 14), and I just tried the Sabrent with the Samsung PM951. It’s recognized with ZUGate, which I use to mount external drives. It properly recognizes the drive and the NTFS partition, but it seems I can’t mount it and it just says “wrong format”. It seems the same with my Liteon drive’s NTFS partition, but I can mount the FAT and EXTx partitions and browse the files. ZUGate says it supports NTFS so I’m not sure what’s going on, but it has been on my list to investigate.
Correct, as far as Windows is concerned, it remained connected.
Interesting. I honestly didn’t even care about NTFS compatibility. I’ve shoved plenty drives with unsupported file systems, or straight up nuked partition map into my phone, and Android will offer an option to format it as long as the drive itself is functioning correctly. The Type-C port’s capability of this phone should also be reasonably adequate. I wonder why this drive doesn’t show up at all.
Edit: Grammar
Let me know if there’s anything else you want me to cross check. I’m about to not have this particular unit of AMD Framework very soon. Unrelated to the Type-C behavior we are looking into, I noticed a different issue on this specific laptop (physical issue, perhaps not even Framework’s fault, but something weird happened during transportation). Framework was very responsible, and quickly took care of me with a replacement. Considering my personal matters could be busy in the next few days and I have a perfectly fine 12th Gen currently using, I’m unsure when I’ll assemble the new replacement. I still ought to send the current AMD unit to Framework very very soon. Let me know if there’s any new discovery that could benefit from me trying to replicate on my side.
Ah yeah, and I just tried without ZUGate and my phone’s recognizing it with “Tap to fix Sabrent” and offering to format. Have you tried another SSD in the enclosure and seeing if it works? Or does does that SSD work with another enclosure?
Edit: to pinpoint where the incompatibility lies. I’d be kinda shocked if you forced USB2 and your phone recognizes it, but doesn’t at USB3. That can shift the root cause back onto the enclosure/SSD along with the host. Though the incompatibilities on your phone and AMD could be discrete cases.
Also, reminder to self to check if a different filesystem makes a difference, though I don’t think it will.
Noted, thanks. It may be a good idea to let Framework know about your experience with this current issue so that they can hang on to the board and tag it so they have something to reproduce the issue reliably with. If they have it and can, it’ll be much easier to root cause.
'pologies for the double post, got some more insight. Per Framework support’s request, I tested with Live Ubuntu (22.04.3 LTS).
I noticed the same behavior, with copying a 10GB file at around 220MB/s from the internal SSD to the enclosure/SSD failing in both the the left bottom and right bottom ports.
However, interestingly if I run dd which copies files from the USB2 speed flash drive (where Live Ubuntu is) to the enclosure/SSD, it will write at the limited USB2 speeds around ~60MB/s and not reset, even if the enclosure is connected at 10Gbps.
So from that, it looks like it doesn’t matter what speed the enclosure is negotiated at, but rather what speed the writes are. When mistakenly negotiated at 5Gbps, it has transferred successfully at 190MB/s, but I don’t think ever at 220MB/s, which is at 10Gbps negotiation (unsure why they’re so low but I think in this case, unrelated). This tracks from what I’ve seen…and now rules out negotiation speed being the cause. I suspect that writes at higher speeds may cause SSDs that are more power hungry to draw more power than the port can provide/handle, causing it to reset. TBD what Framework support says, but I think a few ways to validate this theory are:
1. Limiting write speeds in software to find the threshold when negotiated at 10Gbps
2. Using a powered hub at 10Gbps
3. Using a USB power meter
TBD, and I’ve already ruled out thermal throttling previously.
Edit: tested software write speed limit with rsync --bwlimit, nevermind, still resets even limiting to 50MB/s when negotiated at 10Gbps. Perhaps the USB2 flash drive to USB3 enclosure transfer was limited to the USB2 controller so it worked?
I wanted to replicate this. Filled up a 64GB microSD with large files. I wanted to plug the microSD card and Sabrent enclosure both into the AMD Framework, and copy large files from the microSD card to the external NVMe SSD via AMD Framework. Unfortunately, for some reason the Sabrent enclosure isn’t being recognized at all now. (microSD in card reader popped up immediately)
Section Update 1: Got it to work. USB3 card reader, but the card isn’t capable of exceeding ~90MB/s read, therefore the external SSD isn’t getting more than ~90MB/s write, obviously. Copy lasted under a minutes until the external SSD dropped again. Seems like a low write speed in this scenario doesn’t mitigate the disk drop. (Interesting how when the drive is erroneously slated as 5Gbps upon connection, it was able to finish copying a bunch of large files at a much faster 500MB/s)
When the AMD FW enteres the state of ‘cool down’ right after a disk drop, the external drive won’t even show in the BIOS boot selector. (the disk is bootable, and will otherwise show)
I’ve also worked to rule out the possibility of defective Type-C pass-through Expansion Cards. Plugging the external drive directly into the board with no Expansion Card doesn’t eliminate this issue. I’ve also pulled Expansion Cards off the AMD Framework, linked them back-to-back, plug them into my 12th Gen, connected the Sabrent Enclosure and smashed it with both large file transfer and synthetic benchmark. Works fine.
Yup. It’s about time I really ought to pack up this specific unit of AMD FW and ship it to them. When I email Framework to inform them the tracking number once I have it, I’ll also mention this behavior we are investigating, so if they wish, they can grab this unit for their own testing. Again, if anyone from Framework is reading, I can also provide my enclosure/SSD/cable.
(For anyone just began reading from here. This specific unit is being sent to Framework as I discovered an unrelated physical issue on this unit, perhaps something happened during storage or transportation and irrelevant to the Framework AMD mainboard’s design. It is also unlikely a cause or contributing factor to the Type-C behavior we are investigating. Framework was very responsive when contacted regarding this phsyical issue, and already took care of me with a fresh replacement.)
Edit 1: Fix attachment.
So I just tested in Windows to see if I could reproduce your stated “cooldown period” and I could not, with CrystalDiskMark or transferring a large file. After it disconnects it then reconnects immediately (the same behavior I’ve been seeing on Fedora and Ubuntu).
Also I can confirm, that for Windows USB Device Tree Viewer confirms 5Gbps (SuperSpeed) or 10Gbps (SuperSpeedPlus) under Device Connection Speed. When it negotiated at 5Gbps, CrystalDiskMark was showing around half the throughput vs. what it was at 10Gbps, and Device Connection Speed said SuperSpeed instead of SuperSpeedPlus.
When it was connected at 5Gbps and working with CrystalDiskMark, I let it idle and it went into the breathing blue LED/power-saving mode. When I ran CrystalDiskMark again and it came out of that mode, it stayed connected at 5Gbps, worked as it usually does when it’s connected at 5Gbps in my left bottom port, and did not renegotiate to 10Gbps.
So I couldn’t reproduce that either.
The “cooldown period” and not getting your drive to be recognized at all might be because I’m on BIOS 3.03 while you’re on 3.02, and if so that could mean there were changes that improved stability with our hardware. Which could be promising for the next update. Though it’s odd your S20 phone doesn’t recognize it either.
What in the ever living 
lmao good to know. Time to construct a bridge around the world made solely out of Framework USB-C expansion cards
Before doing so, you could update to BIOS 3.03 just to verify if that does indeed allow the enclosure/SSD to always be recognized and with no “cooldown period” like it does on my mainboard. Though keeping your BIOS on 3.02 might benefit Framework support’s troubleshooting process. Do please mention this and thank you!
An update from my end: Framework support has escalated my ticket and their engineering team is taking a look. wubba lubba dub-dub!
Since you have access to Windows, if there’s nothing important on this external drive (or can conveniently offload important contents elsewhere), can you use Rufus and turn the external drive into a WindowsToGo drive?
Since you are on 3.03, I just thought you can try to boot your Framework Laptop from the WinToGo external drive, run CrystalDiskMark or other disk-intensive activities within the WinToGo OS and see if the whole thing crashes. (Like I said, it will crash for me, enter ‘cool down’, and the drive won’t show in boot selector post-restart) I’m unsure what valuable findings can be gathered from testing WinToGo like this, but since you are on 3.03, maybe poke around, test booting WinToGo on different ports, run different test scenarios, check USB-related parameters, and just to see what shenanigans may surface.
Maybe that’s just my phone. But, what revision of the EC-SNVE enclosure do you have? I’m extremely sure there are multiple revisions under the same ‘EC-SNVE’ model. They do appear to have the same controller, but with different 2280 clamping mechanism and visibly different components arrangement on the PCB.
This is mine.
Yeah. I could, but I’m also concerned that by me updating this AMD unit to 3.03 at this point, it could hinder future investigation.
Since it appears that the team handled my replacement (and currently awaiting my tracking number) and the engineering team are two different teams, I’ll create my shipping label first. Once I have the tracking number, I will reply to the last correspondence I had with Framework to provide them the tracking number, which would likely be received by the same team that’s handling my replacement. Then, in the same email, I’ll go ahead and link them to this whole situation here. Since the support case on your side has been escalated to the engineering team, there’s the possibility that the engineering team can be made aware of my specific unit, which is exhibiting similar fault, and, Framework is taking its ownership one way or another. This way, if they need to, they can grab it.
Update 1:
Replied to Framework in my ticket about the unrelated physical issue, informed them that I’m getting ready to ship out the laptop. I then briefly explained what has been going on with the Type-C compatibility experiment, linked to this post, and strongly suggested them to get in touch with the engineering team that will be handling @Michael_Wu 's ticket.
Will do, not sure when but I need to back up the contents first which I’ve been meaning to anyways so hopefully soon. I’ve tested copying from the enclosure/SSD to itself (self-write), and that exhibits the same reset behavior as copying from the mainboard’s SSD. So I deduced that any large write (and sometimes multiple small writes) negotiated at 10Gbps to the enclosure/SSD results in a reset. So I’d presume that running WinToGo or a Live Linux distro and having it write to itself would result in the same behavior, but maybe there’s something different and we’ll see if I can reproduce that cooldown.
Here’s a pic of mine, it looks like the clamping mechanism and PCB arrangement are the same, as well as 2 lines of text on the front beneath 2142 on your photo (2314 on mine).
wrt to the rest, yeah, and thanks again for making them aware. By the way, how’s the enclosure/SSD with your replacement?
Thanks for the enclosure teardown, I’ll compare more carefully later, to check for any difference. Update: Compared side by side. Seems like we both have R1.2, all surface mount components appears to have identical placements.
I haven’t had the chance to check the replacement yet! But I do intend to make time for it soon.
Did you hear back after your ticket was escalated? I did receive a reply after post #28, I was thanked but didn’t get a definitive yes or no, regarding if I should leave a special note in the box, ship it to a different address, or anything else.
(I’m happy to help if I need to do anything, or if Framework says ‘no worries, we will figure out’ I also won’t protest. I simply want to avoid the situation that if I literally just sent it out, then I receive additional instruction such as leave a note inside with case number).
I privately messaged someone who likely can look into this for us, but this is Friday and I don’t blame them if they won’t check message again until Monday. Now I’m just a bit unsure if I should hold the package for now, or send it right now.
Nope no updates from today unfortunately.
Edit: though I don’t think this is an easy issue to resolve, so it might take a while.
My 2 cents: if there was no deadline or rush from their end, I’d say it wouldn’t hurt to wait until you get a definitive answer. I don’t think them not having your issue unit for an extra few days would hurt them, but it might be inconvenient for them if your package ends up going to the wrong place in the beginning. Though whatever the case, they can probably figure it out and track it down anyways from their records.
If you can’t decide, maybe flip a coin or something 
Yeah. Currently no rush from FW. I’ll perhaps hang tight just for a tiny bit more.
I’m certain everyone at Framework are helpful, and will assist their members from different functional departments when necessary. I just wish to prevent situations like if I send it out right now with the label I have currently, it goes right into a whole RMA pile at the destination, then the engineers decides it is indeed, but at that point it will take some work to process & dig out any specific unit. (I have no evidence to confirm or deny this will be the case, just a plausible theory.)
Update: Shipped with note inside box.
We have a JMS583 (EVOLVEO Tiny N1) NVMe enclosure here, and I can confirm that there are definitely resets at 10Gbps.
It also only works in the top USB4 ports; it is not recognized at all in the bottom USB3.2 ports, or when it is, then it is extremely unstable and the connection does not last. The cable used does not seem to be the issue.
On a different AMD Ryzen machine (Thinkpad T14 Gen3 with Ryzen 5 PRO), I have observed no issues at all.
OS: Arch Linux, kernel 6.7.3-arch1-1, x86_64, BIOS 3.03
FW13 AMD 7840U
Zike Z666 (ASM2464) with Samsung 970 evo plus
works, can umount, no eject.
lspciNon-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983
nothing other than internal NVME SSD shows up in lsblk.
echo 1 > /sys/bus/pci/rescan no effect at all.
OS:
Debian testing/trixie (primary) + unstable (only for firefox), kernel 6.6.15
Quick update on my end: I installed and tested BIOS 3.03b BETA and unfortunately the issue still remains 
I also have the same problem. My bios is 3.03b.
I use ITGZ enclosure. The chip is Realtek RTL9201B-CG. The SSD is Transcend 220S.
Just stumbled over this, my usb4 enclosure has the exact same error. But given it uses the same chipset that isn’t that surprising.
Turns out it works just fine on windows 11 in my case though so it may be a linux issue.
I also tried all the ASM2464 firmware I could find with no change.
Dude, it’s the ssd. I did my testing with a 970 evo, tried a different ssd today and hotpluging just worked. Tried a bunch of others (Samsung PM9A1 and 960 evo, WD SN720, and micron 2450), they all worked. 970 evo again, didn’t work. Still got the 2GB/s limit though
Weirdly it works on windows, and without the 2GB/s limit.
Here’s dmesg with the PM9A1
[ 2042.695386] thunderbolt 1-2: new device found, vendor=0xb8 device=0x2464
[ 2042.695392] thunderbolt 1-2: ASMedia 246x
[ 2043.816398] pcieport 0000:00:04.1: pciehp: Slot(0-1): Card present
[ 2043.816402] pcieport 0000:00:04.1: pciehp: Slot(0-1): Link Up
[ 2043.947251] pci 0000:62:00.0: [1b21:2463] type 01 class 0x060400 PCIe Switch Upstream Port
[ 2043.947300] pci 0000:62:00.0: PCI bridge to [bus 00]
[ 2043.947318] pci 0000:62:00.0: bridge window [io 0x0000-0x0fff]
[ 2043.947326] pci 0000:62:00.0: bridge window [mem 0x00000000-0x000fffff]
[ 2043.947345] pci 0000:62:00.0: bridge window [mem 0x00000000-0x000fffff 64bit pref]
[ 2043.947369] pci 0000:62:00.0: enabling Extended Tags
[ 2043.947491] pci 0000:62:00.0: PME# supported from D0 D3hot D3cold
[ 2043.947526] pci 0000:62:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0000:00:04.1 (capable of 15.753 Gb/s with 16.0 GT/s PCIe x1 link)
[ 2043.947848] pci 0000:62:00.0: Adding to iommu group 3
[ 2043.947960] pcieport 0000:00:04.1: ASPM: current common clock configuration is inconsistent, reconfiguring
[ 2043.957101] pci 0000:62:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 2043.957338] pci 0000:63:00.0: [1b21:2463] type 01 class 0x060400 PCIe Switch Downstream Port
[ 2043.957382] pci 0000:63:00.0: PCI bridge to [bus 00]
[ 2043.957398] pci 0000:63:00.0: bridge window [io 0x0000-0x0fff]
[ 2043.957406] pci 0000:63:00.0: bridge window [mem 0x00000000-0x000fffff]
[ 2043.957425] pci 0000:63:00.0: bridge window [mem 0x00000000-0x000fffff 64bit pref]
[ 2043.957450] pci 0000:63:00.0: enabling Extended Tags
[ 2043.957570] pci 0000:63:00.0: PME# supported from D0 D3hot D3cold
[ 2043.957731] pci 0000:63:00.0: Adding to iommu group 3
[ 2043.957878] pci 0000:62:00.0: PCI bridge to [bus 63-c0]
[ 2043.957896] pci 0000:63:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 2043.958027] pci 0000:64:00.0: [144d:a80a] type 00 class 0x010802 PCIe Endpoint
[ 2043.958062] pci 0000:64:00.0: BAR 0 [mem 0x00000000-0x00003fff 64bit]
[ 2043.958225] pci 0000:64:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0000:00:04.1 (capable of 63.012 Gb/s with 16.0 GT/s PCIe x4 link)
[ 2043.958355] pci 0000:64:00.0: Adding to iommu group 3
[ 2043.966643] pci 0000:63:00.0: PCI bridge to [bus 64-c0]
[ 2043.966668] pci_bus 0000:64: busn_res: [bus 64-c0] end is updated to 64
[ 2043.966679] pci_bus 0000:63: busn_res: [bus 63-c0] end is updated to 64
[ 2043.966702] pci 0000:62:00.0: bridge window [mem 0x60000000-0x77ffffff]: assigned
[ 2043.966708] pci 0000:62:00.0: bridge window [mem 0x6800000000-0x77ffffffff 64bit pref]: assigned
[ 2043.966713] pci 0000:62:00.0: bridge window [io 0x2000-0x5fff]: assigned
[ 2043.966718] pci 0000:63:00.0: bridge window [mem 0x60000000-0x77ffffff]: assigned
[ 2043.966723] pci 0000:63:00.0: bridge window [mem 0x6800000000-0x77ffffffff 64bit pref]: assigned
[ 2043.966727] pci 0000:63:00.0: bridge window [io 0x2000-0x5fff]: assigned
[ 2043.966732] pci 0000:64:00.0: BAR 0 [mem 0x60000000-0x60003fff 64bit]: assigned
[ 2043.966751] pci 0000:63:00.0: PCI bridge to [bus 64]
[ 2043.966757] pci 0000:63:00.0: bridge window [io 0x2000-0x5fff]
[ 2043.966765] pci 0000:63:00.0: bridge window [mem 0x60000000-0x77ffffff]
[ 2043.966772] pci 0000:63:00.0: bridge window [mem 0x6800000000-0x77ffffffff 64bit pref]
[ 2043.966782] pci 0000:62:00.0: PCI bridge to [bus 63-64]
[ 2043.966787] pci 0000:62:00.0: bridge window [io 0x2000-0x5fff]
[ 2043.966795] pci 0000:62:00.0: bridge window [mem 0x60000000-0x77ffffff]
[ 2043.966802] pci 0000:62:00.0: bridge window [mem 0x6800000000-0x77ffffffff 64bit pref]
[ 2043.966812] pcieport 0000:00:04.1: PCI bridge to [bus 62-c0]
[ 2043.966817] pcieport 0000:00:04.1: bridge window [io 0x2000-0x5fff]
[ 2043.966823] pcieport 0000:00:04.1: bridge window [mem 0x60000000-0x77ffffff]
[ 2043.966828] pcieport 0000:00:04.1: bridge window [mem 0x6800000000-0x77ffffffff 64bit pref]
[ 2043.967635] pcieport 0000:62:00.0: enabling device (0000 -> 0003)
[ 2043.967793] pcieport 0000:63:00.0: enabling device (0000 -> 0003)
[ 2043.968142] nvme nvme0: pci function 0000:64:00.0
[ 2043.968148] nvme 0000:64:00.0: enabling device (0000 -> 0002)
[ 2043.969957] nvme nvme0: Shutdown timeout set to 10 seconds
[ 2043.976137] nvme nvme0: 16/0/0 default/read/poll queues
[ 2043.978196] nvme0n1: p1
[ 2046.503717] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[ 2051.836967] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[ 2057.170185] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
Yeah, it seems like this issue isn’t within the scope of 3.03b EC firmware.
Thank you very much for sharing your controller and SSD models!
It does seem that some external SSD works better than other. However, given the totality of the circumstances, I would rather say it’s the AMD Framework, than it is the SSD. Especially when during my testing, the same SSD and enclosure works completely fine on every other computers I can get my hands on, including Intel Framework.
(I don’t mean to be a jerk and picking on your words, I’m just sharing my opinion and conclusion on the topic under discussion)
Given that other Type-C related issues on AMD13, such as the single-cable Type-C monitor compatibility issues, are also well-discussed by other owners, including some opening their corresponding support ticket, I would appreciate if FW can comment on this issue. Such as if the cause is identified, and if the pending 3.04 BIOS includes improvement and fixes on Type-C related functionalities.
Probably a combination of both, the enclosure works fine with other ssds and with this one on windows.
I don’t really have access to any other usb4 capable devices and in tb fallback mode the 970 evo worked on linux too. It is a quite weird and speciffic issue for sure.