FW16 Electrical Specifications (MB/DB Pinout Clarification)

[BTek]

Greetings, I have been working on an extended battery solution and I’m at the point where I’m digging into the electrical specs of the fw16. Following the information available on github I’ve started to prototype a solution, getting into the electrical specifications now I’d like to know if anyone can clarify a few things. I’m not an EE but have built simple circuit boards in the past and of course worked with Pi’s/Arduinos and decided I want to start fiddling with my fw16.

While there is documentation and I appreciate that it exists, I immediately ran into some things I’m going to need more clarity on from the specs.

As per the information here : ExpansionBay/Electrical at main · FrameworkComputer/ExpansionBay · GitHub

VADP_GPU - appears to be available to both send or receive power, is this correct?
The pins have a current of 0.75A - is this managed per pin? What I’m getting at here is would I expect to get a maximum of 4.5A using all the pins, what if I used just two? Would current then be limited to 1.5A in either direction? Or is this merely a theoretical/safe maximum?

GPIO0_EC - This is labeled as “I/O pin for second battery” and has a type of CMOS, and OD as input/output. So first, clarification on that? This is under the power section still so I wouldn’t expect these to be a type of communication/I2C but this description makes it seem like its some sort of communication pin?

GPIO1_EC - Description of this pin is “Connect to EC GPIO on mainboard, control 2nd battery discharge and DP_HPD from dGPU PD controller.” And frankly, this means nothing to me, what is EC? What is DP_HPD? What is the dGPU PD controller? Seems like some sort of power management.

Finally what are the fan connectors, is there a part # or equivalent that I can use to order a matching set should I end up going through with making a DB? On that note - which pins are connected to each fan header, does it matter? One set goes to the left fan and one goes to the right fan I presume.

If I had to summarize my ask here for the electrical solution, its this : Is there an existing combination of pins that can be used to manage both the charging and discharging of an additional battery, and if so which ones to use? In addition to that are any of these setup to communicate back to the fw16 regarding battery status, and if so which ones? Does there need to be a handshake process to control the flow in/out of power or can it merely flow as voltage/electrical demand dictates?

The battery itself will have some safety circuits built into it but I’m trying to figure out how complex the transfer of power to/from the fw16 needs to be after that.

[MJ1]

Welcome to the forum.
Since it seems you might be ideally hoping to get answers from Framework staff, in case you’re not aware I want to mention that while Framework staff does sometimes read and answer questions, they’ve said this forum is not an official channel for support. You could try contacting support, but with technical questions such as these it might take some time and perhaps effort or luck to get it directed to where someone knows and could get back to you.

I don’t have any direct information beyond what Framework has shared on the forum and resources like github, but if I may, I think a couple of your assumptions on the pins are mistaken.

@BTek

VADP_GPU - appears to be available to both send or receive power, is this correct?

Each of the high current power paths appear to be for sending in a particular direction only. Iirc that’s what I got from the notes column for the pins.

@BTek

The pins have a current of 0.75A - is this managed per pin? What I’m getting at here is would I expect to get a maximum of 4.5A using all the pins, what if I used just two? Would current then be limited to 1.5A in either direction? Or is this merely a theoretical/safe maximum?

I really do not think there would be independent current sensing on every individual pin. That’s just added complexity (+ cost) for something that doesn’t seem to have any need. I would be certain the current pulled or pushed is within the limit of what FW lists for the number of pins connected. I’d really just connect all of the power pins.

@BTek

GPIO0_EC - This is labeled as “I/O pin for second battery” and has a type of CMOS, and OD as input/output. So first, clarification on that? This is under the power section still so I wouldn’t expect these to be a type of communication/I2C but this description makes it seem like its some sort of communication pin?

Iirc there are a few data pins in the power section, and also vice versa, a few power pins in the data section.

@BTek

GPIO1_EC - Description of this pin is “Connect to EC GPIO on mainboard, control 2nd battery discharge and DP_HPD from dGPU PD controller.” And frankly, this means nothing to me, what is EC? What is DP_HPD? What is the dGPU PD controller? Seems like some sort of power management.

EC is the Embedded Controller. It’s the microcontroller in devices like laptops, responsible for a lot of different things. A lot of low level functions are done by it.
DP_HPD, I believe that would be Display Port Hot Plug Detection. Assuming it’s how the dGPU module, when that is present in the bay, communicates that there has been a hot plug event.

It sounds like GPIO0_EC and GPIO1_EC are meant to serve different functions depending on what’s occupying the bay.

@BTek

Finally what are the fan connectors, is there a part # or equivalent that I can use to order a matching set should I end up going through with making a DB?

They looked like fairly standard 0.5mm pitch ffc connectors. It seems there is a part number here that you could search to check github.com/FrameworkComputer/ExpansionBay/blob/main/Dual%20SSD%20Reference%20Design/ssd%20holder_r00_20230105pm.pdf

I suspect you may not be able to get a battery module to work without contact and assistance from FW. As I suspect the current EC firmware may not yet have everything in place to support / enable a battery module to work. If I recall, with the Dual SSD ExpansionBay module, a firmware update came along with it to support it.

The EC firmware has been open sourced by FW and is on their github. So you could check how it handles those gpio pins, see if code is present to support a battery module, and what it wants as far as communication in order to accept power and potentially provide charging as well.

[BTek]

@MJ1

Each of the high current power paths appear to be for sending in a particular direction only. Iirc that’s what I got from the notes column for the pins.

I believe you are correct, but this is the case for VSYS_GPU whereas VADP_GPU, which are the pins I would expect to be using are I/O. Unless I’m looking at outdated information of course.

@MJ1

They looked like fairly standard 0.5mm pitch ffc connectors. It seems there is a part number here that you could search to check [link removed]

So far looking up the part number returns no exact matches but since this is looking more and more like I’m going to need official FW input perhaps they will have a better lead. It looks like the P/N is a1001-wr-s-04pnlnt1t00r and the only search result so far lands me to a part made by JointTechElec called “Wire-To-Board-Wire-To-Wire-Connector_HR-Joint-Tech-Elec-A1024WRA-S-04PNLNT1T00R_C462083”

I will dig around with this brands other offerings to see if I can find a better match, this one doesn’t look quite right.

@MJ1

I suspect you may not be able to get a battery module to work without contact and assistance from FW. As I suspect the current EC firmware may not yet have everything in place to support / enable a battery module to work.

Looking at the code here on github : EmbeddedController/baseboard/fwk at fwk-hx20-hx30-4410 · FrameworkComputer/EmbeddedController · GitHub

I can see that there is a whole class dedicated to battery but I’m a bit concerned this isn’t for the FW16, as the battery models are ADL-55W and RPL-61W which would seem to line up with the Framework 13 battery sizes of 55wh and 61wh respectively. Makes me a bit concerned I’m not looking at the right branch or area. I’ll keep digging but this might also need input from FW themselves.

Finally while looking at more official FW documents I came across the note below about a custom standoff being a requirement for the interposer connection:

Note that one custom part is needed for development: the threaded insert that the interposer screws into. Two pieces are needed on each Expansion Bay Module. A drawing is in the PCB Reference Design folder. You can submit a request for free samples of these for development purposes at: [Link to google doc here]

So it is very much looking like I am going to need some help from FW themselves before I can make much progress on this at all. I will of course update this thread as soon as I get details from them, IF I get enough information to proceed further.

[MJ1]

@BTek

I believe you are correct, but this is the case for VSYS_GPU whereas VADP_GPU, which are the pins I would expect to be using are I/O. Unless I’m looking at outdated information of course.

I’m sorry, I’m not sure I’m following you.
From what I understand VSYS_GPU is the path for power going from the laptop to the Bay, and VADP_GPU is the path for power from the Bay going to the laptop.
See here for a power block diagram that includes VSYS_GPU, VADP_GPU and a eGPU or a battery in the Bay:

Expansion Bay Developer Program

The power block diagram looks like this: [image] LM5143 supports a wide input range and ISL9241 is a buck/boost that can output the end 19V rail. As you noted, one tricky thing on this is that the Expansion Bay Module would need to communicate with the rest of the PD controllers through the EC to ensure that only one power source is enabled at a time. That is something we haven’t defined yet.

Nrp's image (click to show)

@BTek

by JointTechElec called “Wire-To-Board-Wire-To-Wire-Connector_HR-Joint-Tech-Elec-A1024WRA-S-04PNLNT1T00R_C462083”

I will dig around with this brands other offerings to see if I can find a better match, this one doesn’t look quite right.

Hmm, yeah that A1024WRA-S-04PNLNT1T00R definitely can’t be it. Since the pictures of the board and the fan cable just show a 4 pin FFC connector. If you wanted to, you should be able to figure out if it’s 0.5mm pitch or 1mm pitch by using other components as reference. Very likely to be one of those.

Pictures (click to show)

As long as it’s for a non- notched cable (as the fan does show) FFC connectors seem to be pretty standard. For random projects, when I didn’t want to pay for shipping from a proper supplier, I’d just order whatever random one I need from ebay or aliexpress. Just searching for example, 1.0mm pitch 4p FFC connector.

@BTek

Looking at the code here on github : EmbeddedController/baseboard/fwk at fwk-hx20-hx30-4410 · FrameworkComputer/EmbeddedController · GitHub

I can see that there is a whole class dedicated to battery but I’m a bit concerned this isn’t for the FW16, as the battery models are ADL-55W and RPL-61W which would seem to line up with the Framework 13 battery sizes of 55wh and 61wh respectively. Makes me a bit concerned I’m not looking at the right branch or area.

Oh yeah, that wouldn’t be FWL16, as hx20 and hx30 are the board names / codenames for the intel 11th & 12th gen respectively. Lotus is the AMD FWL16.

This confirms Lotus is the AMD FWL16: Open source EC for AMD based 13/16.

I saw someone give a nice list of all the FWL13 names once. I failed to note them down, but think I found it here: How to configure the F9 Fn (display switch) key? - #3 by vriska.

So, Embedded controller firmware

Laptop Generation	Board Name
Intel 11th Gen · Framework Laptop 13	hx20
Intel 12th Gen · Framework Laptop 13	hx30
AMD 7040 Series · Framework Laptop 13	Azalea
Intel Ultra Series 1 · Framework Laptop 13	Marigold
AMD 7040 Series · Framework Laptop 16	Lotus

@BTek

Finally while looking at more official FW documents I came across the note below about a custom standoff being a requirement for the interposer connection:

I don’t know if that’s a hard requirement. Like, if you’re just making prototypes or a few boards for yourself & perhaps a few others. You just need a nut that fits the interposer screws. The FW custom standoff is presuming you want / need it to be a proper PCB mounted nut which can be inserted in mass productions runs. You may be able to just glue an embedded insert to the PCB (such as is used for embedding into plastic parts).

[BTek]

Great links, especially the block diagram thanks. Some questions answered, and yet more raised. I’ll take some time to digest this further.

@MJ1

From what I understand VSYS_GPU is the path for power going from the laptop to the Bay, and VADP_GPU is the path for power from the Bay going to the laptop.
See here for a power block diagram that includes VSYS_GPU, VADP_GPU and a eGPU or a battery in the Bay:

This may just be some inconsistency to the documentation, perhaps I’m misunderstanding it? I do agree the block diagram appears to agree with what you say, but the markdown on the github does have some conflicting information which is where my journey started.

Referencing this : ExpansionBay/Electrical/README.md at main · FrameworkComputer/ExpansionBay · GitHub

Take for example pin 1 in the power section VSYS_GPU, it is labeled under I/O as “I” and the description is “Main power rail to Expansion Bay Modules from Vsys.” All in agreement here, this makes sense. This is an input to the expansion bay.

Referring to pin 41 - VADP_GPU it is labeled under I/O as “I/O” which would lead me to believe that it can be either input or output, but the description does say “This allows power to be fed from the Expansion Bay back into the laptop in an Extended Battery scenario…”

So the description and block diagram do seem to point to this as being an output from the expansion bay as well, but it is categorized as I/O in the markdown. A bit confusing.

To further confuse things, pin 41 says a voltage range of 7-20 is expected according to the markdown but the block diagram shows +48v max for this VADP_GPU “bus.” So now I’m questioning what my safe voltages on either of these sets of pins would be too

@MJ1

This confirms Lotus is the AMD FWL16: Open source EC for AMD based 13/16.

This is very helpful, I’ll spend some time going through the proper code this time and see if anything catches my eye.

[MJ1]

@BTek

Referring to pin 41 - VADP_GPU it is labeled under I/O as “I/O”

I didn’t even pay attention to the I/O column for the power pins! Just went by the description & purpose listed.

I think it’s just a typo / error.
See pin 15 - GND - O - “Ground for VSYS_GPU”. And the ground pins labeled as being for VSYS_GPU. VSYS_GPU is I in I/O column, 15-26 GND is O in I/O column. Matching the common view of the flow of power / electrons for DC, positive and negative (that negative is the return). And all the other DC power pins present for various purposes follow the same arrangement.

VADP_GPU is the outlier. And note that it’s matching GND pins 47-51, do not say I/O, instead they list “O”, following the same arrangement as all other power pins. Pin 47 - GND - “Ground for VADP_GPU”. A DC positive and it’s negative / ground are a pair. They must follow each other, so one of the two sets of I/O columns must be wrong. And everything else points to VADP_GPU being just being used in one direction. So the VADP_GPU I/O column seems to be the one that’s wrong.

@BTek

To further confuse things, pin 41 says a voltage range of 7-20 is expected according to the markdown, but the block diagram shows +48v max for this VADP_GPU “bus.” So now I’m questioning what my safe voltages on either of these sets of pins would be too

Well, note that voltage column doesn’t say max anywhere. For power supplies like this (expected to vary with battery level, and / or the source, exact regulation done elsewhere) there is always an acceptable range. Even inputs on consumer electronics, like a wifi router, modem, etc, it will say something like “12v DC” at the power port, but the power circuity actually has a range that it’s perfectly happy with. Now for power lines for specific purposes that are clearly meant to be already regulated, such as 5V_ALW, 3V3_ALW, 12V_FAN, those should not vary.

7-20 I would think is just what is expected. And the pin 1 notes explain why that range is what’s expected.
+48v matches USB PD 240W which is 48v @ 5A, and this would allow the Framework 16 to accept full voltage from a 240W USB PD power supply plugged into an Expansion Bay module.

Oh, and in the power block diagram, note that “FBeam” is the name for the interposer connection. And also note the presence of switch symbols on the laptop side of both VSYS_GPU and VADP_GPU lines. Plus, Nrp mentioning that “the Expansion Bay Module would need to communicate with the rest of the PD controllers through the EC to ensure that only one power source is enabled at a time”. So in the normal operating situation the EC should have the VADP_GPU’s switch open / the line disconnected to prevent accidentally having two power sources running headlong into each other.

[Alan_Pearce]

@BTek

GPIO0_EC - This is labeled as “I/O pin for second battery” and has a type of CMOS, and OD as input/output. So first, clarification on that? This is under the power section still so I wouldn’t expect these to be a type of communication/I2C but this description makes it seem like its some sort of communication pin?

The battery control electronics uses I2C to communicate with the EC. The ‘colomb counter’ IC in the battery keeps track of the state of charge of the battery, and informs the EC of the details.