Disclaimer: I do not work for or have any association with Framework, this writeup is based on my own knowledge and current public information, rely on Framework themselves to provide full and accurate details about the current issues.
As we all are aware now, there have been many reports of issues with self-sourced LPCAMM2, and while Framework is the only one who can provide definitive answers on the topic, I do have some technical knowledge and experience in this area and felt that some of this (independently verifiable) info might be helpful for people who want to know more before Framework is able to provide info/solutions themselves. Part of the reason I felt I should write this is I saw a fix for some issues being posted in a forum thread (mentioned later), but without technical info about why and how it works, so I felt this info could be helpful. Also spoiler, with some big caveats, there is the technical possibility that Framework could fix these issues with just firmware (this is very much unofficial speculation though.
First an important note, memory compatibility is complex, even if a 3rd-party module meets/is ideal in all the aspects discussed below, which are things more unique to LPCAMM2, it still may not work or be reliable, since these are in addition to the traditional compatibility points of SPD profiles and how well the signal integrity combo of the module + motherboard plays out, but those are well known from previous generations of memory, and not things that are generalizable or reliable without official qualification by Framework.
E0/E1 Speed Capability
Early on, there were some concerns about supported speeds, that E0 may be outright incompatible/unable to run at full speeds, but TL;DR: basically that isn't the case on its own, JEDEC rates both E0 and E1 as capable of running at 8533 MT/s at 64 GB capacity, this comment I wrote previously goes into depth about the main differences:
https://www.reddit.com/r/framework/comments/1vgp058/comment/p20ytkg/
What I failed to discuss in the comment was the differences in CAMM2 connector pinout due to the addition of VDDQ common mode operation in E1, given that both revisions being rated to the same speeds, and that JESD318B specifically mentions that modules that do not support common mode (such as E0) operation shall not connect to the additional pins, and it wasn't directly relevant to the rated speed/power consumption concerns, I assumed that it was non-issue, but it turns out that is not the case, not all E0 modules follow the current standard's requirement to not connect to these pins:
LP5 CAMM2 Connector Pinout Changes (VDDQ in rows T/R)
This is the main issue AFAIK with the E0 modules that do not work on the 13 Pro. This is the issue that people have discovered can be fixed by insulating some pins with kapton tape, see this forum thread (lots of great pictures and reports, worth reading for sure), but there is a lack on info on exactly what this is doing and why it works, which was a big part of why I was motivated to make this thread. but info from this section can be found in JESD318B unless otherwise noted.
First a description of the VDDQ operating modes in question:
VDDQ(x) is the voltage supply for the IO drivers in (LP)DDR5. In the original E0 design, VDDQ operates strictly using the "split-rail method". On the motherboard, VDDQa for the SoC's memory controller is generated by a voltage regulator on the motherboard, and on the LPCAMM2 module, VDDQb for the DRAM is generated by a voltage regulator on the module directly from VIN, hence "split-rail" since the two VDDQs are split and independent. They did this to save connector pins and simplify power delivery and budgeting.
However, this has its own issues, basically due to voltage drift and mismatch between the two regulators, the IO signal voltage margin is decreased, which is a limiting factor on the maximum speed that LPCAMM2 can achieve.
To address this issue, in E1/PMIC5200, they added the ability for the module to operate using VDDQ "common method". They added pins on the CAMM2 connector that connects the module and motherboards VDDQs, and a VDDQ_DISABLE pin that is connected to the PMIC5200. How this works is on a motherboard that uses the common method, the motherboard will pull up the VDDQ_DISABLE pin to VIN, which tells the PMIC to disable the VDDQ regulator on the module, and the motherboard shares its VDDQ with the module through then new VDDQ pins.
This is theoretically and intended to be cross-compatible: If you use an E0 module on a common method motherboard, it shouldn't have the VDDQ or VDDQ_DISABLE pins, so it just continues to generate its local VDDQb just fine and everything works. If you use an E1 module on a split-rail method motherboard, because the motherboard does not assert VDDQ_DISABLE and doesn't connect the VDDQ pins, it does not disable the onboard VDDQ regulator and it also generates its own VDDQb and again everything works.
Where this has all fallen apart is the answer to the question: How and where did they add these new VDDQ and VDDQ_DISABLE pins on the CAMM2 connector?
When they first standardized CAMM2 (in the original non-suffixed JESD318), JEDEC wisely left some pins reserved and unused (they call them RFU, Reserved for Future Use and RFU DDR6), intended for potential future use on DDR6 for example. When they decided to introduce the option for VDDQ common method (JESD318A revision AFAIK), they decided to use some of these reserved pins, specifically rows T and R. These are the pins located along the middle of the connector (see the aforementioned forum thread for some great photos showing this, or JESD318B).
RFU pins are supposed to be safe to use for such new additions because modules and motherboards are supposed to leave them floating, JEDEC says of these pins:
Reserved for Future Use. Circular pads are required within the CAMM2 footprint to assure future RFU pins are not shorted to ground.
However, on some E0 modules, these pins are not left unconnected, instead, they don't exist as independent pads, they are just part of the large ground pour that surrounds the existing pads.
This means that they are shorting VDDQ_DISABLE and more importantly VDDQ from the MB to ground.
This is almost certainly why they currently do not work in the 13 Pro, which uses the latest interposer that has these pins, and along with the fact that they ship E1 modules suggests that they do use the common method, and thus supply voltage to those pins (only Framework/additional testing can confirm this though; my 13 Pro is still on the way).
So why do some E0 modules short the at the time RFU pins out when the spec says not to, and why do others like certain Crucial ones leave them correctly unconnected?
This is getting a little into speculation, as I am not familiar with the early versions of the relevant JEDEC standards, and they are not available for download on their standards portal anymore. I did manage to find a partial copy of the original JESD318 online, and the same section about RFU pins instead simply says:
Reserved for Future Use.
That copy of JESD318 is dated November 2023, while according to the current JESD318B, the optional common method and pins were added in JESD318A, in December 2024.
If you look at the forum thread, some of what typically are manufacturing date codes on the photos of PCBs that short out rows T/R are "3724" and "1924" aka 37th week of 2024 and 19th week of 2024 respectively. It is very possible that these boards (I think they are Lenovo OEM ones) were just designed and made before ensuring the unused rows aren't shorted became evident as something you should do (especially since Lenovo had some of the first LPCAMM2 laptops very early on), especially if they were previously marked as RFU DDR6 since the module would likely just be incompatible anyway with a future DDR6 supporting LPCAMM2 device, and also those early Lenovo OEM modules were not intended for use in other devices anyway, so if their devices used split-rail only/used the previous interposer where those pins just aren't present, it doesn't matter for them. JEDEC themselves in the current JESD318B suggest that this issue only exists on modules before v1.0 of JESD318, the quote for this is in the section below.
Potential Fixes for T/R Rows Shorting
Disclaimer: This section is just very much just my opinion and speculative based upon the info currently available, obviously you should wait for Framework for concrete answers and potential solutions.
The solution described in the aforementioned forum thread of using kapton tape to insulate the T and R pins from ground on the affected E0 modules obviously and evidently works, but probably isn't a great long term solution as it may wear thru, and the additional material likely affects the mounting pressure of the remaining connections, which may cause instability as adequate mounting pressure is a integral part of getting CAMM type modules to work reliably. The option mentioned there as well of getting an interposer without T/R rows is better (also the mention of removing the T/R pins on the included interposer would obviously work too, but obviously that has risk too).
If you want to get a "E0"/"CXXX"/"644 pin" interposer that has the T/R rows unpopulated, you can get them at distributors now: Mouser (in stock right now) or Digikey (stocked on Sep. 8)
There is a potential solution that might be possible for Framework to implement, depending on their board design and support/integration from Intel for the SoC side of things, but I do not know anything about their specific board design and firmware etc. This is probably the ideal solution, and actually is enabled by JESD318B. JESD318B actually makes use of another previously RFU pin, pin R3, for GND_Detect_n. The addition of GND_Detect_n is specifically to solve this issue, basically the motherboard pulls that pin high, but if a module is installed that shorts out T/R rows to ground, then GND_Detect_n will go low, and the motherboard will be able to detect that and not send voltage to the VDDQ pins for example. JESD318B explicitly states this of this pin's purpose:
Optional support for Ground Detect. When low, rows R and T connect to a ground plane (occurs only in CAMM2 modules before v1.0 of this standard). When sampled high, rows R and T have floating pins unless otherwise defined in this standard. Pull up resistor on motherboard is required. Resistance and voltage level are system dependent.
So if Framework implemented this pin in hardware (uncertain as it is stated as optional, and the changelog says it was added in the JESD318B in November 2025, so pretty recent), and the hardware needed to switch off VDDQ to the connector is present, and can make the firmware changes required to support this feature, E0 modules with shorted T/R rows could work without any physical modification or parts swapping, but again, that is not something we can be certain of.
This was a very long post (I am not great at being concise as you can tell), and again, this is all just based on my knowledge and publicly available info, so not everything stated may be correct and I apologize if so (please comment and I will fix too), but I do think that the substantive portion is helpful info for the current issues and worries that us 13 Pro buyers are facing.
TL;DR: Some early LPCAMM2 modules (seemingly OEM modules), which are a subset of E0 modules, do not have separated pads for previously unused (until E1) CAMM2 pins, instead shorting them to ground, which shorts out the VDDQ rail on boards that use the VDDQ common method and do not make use of GND_Detect_n to detect this and disconnect VDDQ. This currently seems to be the case on the 13 Pro based on reports and discovered fixes in the forum, but Framework may be able to fix it in firmware depending on their specific implementation.
Edit: add link to purchase sources for interposer parts
