Ryzen 7040 External Monitor and NVMe Enclosures

I upgraded my 1240P Framework Laptop 13 with a 7840U mainboard, 2x 16 GB of DDR5-5600 from Crucial, 2 TB Solidigm P44 Pro, a 61 Wh battery, and a fresh Windows 11 install. I have the following issues that I believe the community might be able to assist with.

Charging

On BIOS version 3.03, my Framework has problems with some chargers, and I detailed the issue here.

USB Powered Portable Monitor

I own this external monitor. With my 1240P mainboard, I can output display and power to the monitor simultaneously via USB-C. With my 7840U mainboard, I can either output display or power to the monitor, but not both simultaneously via USB-C. I have confirmed I am using the correct ports (I’m using the rear left port and tried the rear right port). I can, however, output the display signal while receiving power (when the display is powered with an appropriate USB-PD charger).

External NVMe Enclosures

I own two USB 10 Gbps external NVMe enclosures A and B. These worked fine with my 1240P mainboard when paired with this SSD. However, neither of these enclosures works on my 7840U mainboard. They receive power, but the SSD is not detected. I have verified the enclosures and SSD still works with my Windows desktop PC.

1 Like

Well that is pretty concerning, those are 2 things I use with laptops pretty regularly.

Can’t help with solving the issue, but I’ve got the same mainboard and use a different enclosure without any issues. I also tested a different portable monitor that we had at work which worked fine. So I can at least confirm that USB-C monitors and NVME enclosures should work.

I am on Linux though, so it’s possible that maybe Windows has some problem with them, but it’s probably worth contacting Framework support if you haven’t already, as it seems likely that there might be an issue with the board, or maybe those particular devices do something the firmware wasn’t expecting or something like that.

Edit: For info, I’m also on BIOS 3.03

2 Likes

Just tried this with mine, works on all 3 display-port capable ports without problems or external psu.

Also tried the ones I had on hand (both RTL9210* based), work fine both on usb-c and A

1 Like

Is my main board just broken? I’ll contact support after the holiday.

1 Like

Potentially, though it is also possible you just happen to have the 2 non compatible samples or I just happen to have the 3 compatible ones XD.

1 Like

@Kelly_Wu were you able to resolve your NVMe enclosure issue?

I’m having a similar issue (worked on my 11th gen Intel and other devices), detailed here.

Sorry to hear that, I am using a nvme enclosure just fine without a problem but from this manufacturer . Can you confirm that it is even recognized by device manager? Though I can not confirm if it works on Windows bc I only use Linux and the drive is formatted with ext4.

Btw, that enclosure is said to be using the Realtek RTL9210B chipset which is the same as both of these enclosures:

@Michael_Schmid could you post the SSD you’re using here and/or the other thread, and specifically is sustained transfer to the SSD (a 10GB file) okay? Would be helpful and thanks in advance.

I’m fairly sure it’s not an enclosure issue but rather an SSD (likely NVMe) compatibility issue. @Kelly_Wu also, seeing if the enclosures are recognized without the SSD could provide clues. When plugging in the enclosure without the SSD, it should show up in Windows device manager under Disk drives and if not, you could try running the Realtek firmware updater tool and seeing if the enclosure is recognized (again, without the SSD). Another option is plugging the enclosure with the SSD in Linux and seeing if it shows up in journalctl logs. Lastly, testing with another SSD.

Drive: Crucial P3 Plus 2TB NVME CT2000P3PSSD8

dd-transfer with /dev/random

sudo dd if=/dev/random bs=1G count=10 of=transfer_test status=progress  
10737418240 bytes (11 GB, 10 GiB) copied, 30 s, 354 MB/s 
10+0 records in
10+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 30.3159 s, 354 MB/s

dd-transfer with /dev/zero

sudo dd if=/dev/zero bs=1G count=10 of=transfer_test status=progress  
10737418240 bytes (11 GB, 10 GiB) copied, 13 s, 808 MB/s 
10+0 records in
10+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 13.2947 s, 808 MB/s

Hope this is enough.

1 Like

@Michael_Schmid magnificent, thank you! That helped tremendously here. It seems that both a singular 10GB file write or multiple files written continuously that equate to 10GB both can result in a reset.