M2 Interface Definition¶

Scope¶

The local proposal workbook's M2 and M2xM sheets number positions 1–75 but omit positions 24–31 from the contact map, leaving 67 numbered contacts. Both sheets label the map as an M.2 Key-E connector; the M2xM sheet also says the M2 baseline must be included in the same module. These are proposal labels, not evidence of conformance with the PCI-SIG M.2 specification, module-to-carrier interchangeability, or the number and arrangement of physical connectors. M2xN and M2xA appear only as summaries on this page; no source contact maps for them were found.

• M2 — connected display, audio, storage, debug, and general embedded I/O.
• M2xM — draft multimedia display, camera, and PDM allocation. I2S/PCM is mentioned in the draft summary but has no assignment in the available M2xM sheet.
• M2xN — networking, USB, CAN, and UART signals.
• M2xA — motor control, analog acquisition, encoder, and timer signals.

M2xH and M2xP remain naming reservations; no contacts are assigned to them in the current draft.

Connector convention¶

In the local proposal workbook's M2 sheet, odd-numbered contacts are shown on the top side and even-numbered contacts on the bottom, viewed from the card edge. Positions 24–31 are absent from the contact map and identified as the proposed key/notch area; this drawing does not establish mechanical conformance with the M.2 E-key specification.

M2 base profile¶

M2 is the base profile for compact connected products. Its allocation is intended to cover a QSPI display and capacitive touch panel, Wi-Fi SDIO, 1-bit TF-card SDIO, analog audio, debug, USB, CAN, and general buses. Several contacts are intentionally multiplexed so that one module can select the function appropriate to its SoC and product configuration.

Color-coded M2 pinout¶

The colored bar is the table key. The two-sided contact table below records this M2 proposal's reference pinout, including alternate functions and multiplexing; it is not a released interface specification.

M2 contact assignment¶

This two-sided grid uses Bottom Pin / Top Pin / CN1 columns. The Alt columns record an additional multiplexed function when the workbook assigns one. Every function cell uses its category color from the legend above.

M2 pin descriptions¶

The groups and colors match the contact table above. The workbook does not define I/O directions, so this column is provisional integration guidance, viewed from the module: I means input, O means output, and I/O means bidirectional. Comma-separated directions follow the listed signal order. SPI and PDM entries assume the module supplies the clock; SWD entries assume an external debugger. Confirm every direction and electrical requirement against the selected module and SoC documentation.

For I2C, I/O describes the bidirectional SDA/SCL bus lines, not a guarantee of every controller/target mode or clock-stretching capability. Confirm pin configuration and pull-ups for the actual module. See NXP's I2C-bus specification. The PDM clock-output/data-input assumption follows the microphone-host arrangement illustrated in ST's PDM application note; it does not establish support on a particular module.

M2 sharing rules¶

• The workbook marks SWD as a multiplexed resource with two alternative routing options: the debug-UART positions (SWDIO on pin 43, SWCLK on pin 41) or the touch interrupt/reset positions (SWDIO on pin 51, SWCLK on pin 49). Populate only one option per module and reserve a recovery strategy before reusing any of these contacts.
• SPI1 is shared with the 1-bit TF-card path; both are also exposed as the generic SDIO1_D0–D3/CMD/CLK controller bus, and pins 65/67 additionally carry CAN_TX/CAN_RX.
• The Wi-Fi SDIO2 data lines are also exposed as the generic SDIO2_D0–D3/CMD/CLK controller bus; several of the same contacts double as GPADC analog inputs.
• SPI2 and I2C3/I2C4 (contacts 58, 56, 54, and 52) can alternatively carry PDM1/PDM2 digital-microphone signals, plus generic G0–G3/BUS0–BUS3 GPIO aliases.
• In the six-position G11–G16/BUS11–BUS16 group, UART3 uses contacts 38/36, UART2 uses 39/37, and I2C2 uses SDA/SCL on 35/34. These are distinct pairs, not three buses sharing identical pins. Each pair shares its contacts with the corresponding GPIO aliases; confirm simultaneous operation on the selected module.
• The QSPI display and capacitive-touch groups are separate at the signal level, but their power, reset, and wake behavior must be reviewed as one display subsystem.
• CAN_TX and CAN_RX are logic-level signals multiplexed onto pins 65/67, not separately allocated contacts. The carrier still needs a CAN transceiver and protection appropriate to the product bus.

M2xM multimedia profile¶

M2xM is a draft multimedia allocation. The local proposal workbook marks DPI and DVP as primary signal groups and MIPI DSI and CSI as alternatives, but does not define mux control or concurrent-use constraints. These labels do not establish support on a particular μForge module or SoC package; confirm device capability and routing in the selected module documentation before implementation.

M2xN networking profile¶

M2xN is an unverified networking-profile summary in this document, not a source-backed contact map. The available proposal workbook has no M2xN sheet, and no primary SiFli source for these assignments was found. The signal list and reserved-contact counts below must not be treated as verified.

M2xA analog and motion-control profile¶

M2xA is an unverified motor-control and acquisition summary in this document, not a source-backed contact map. The available proposal workbook has no M2xA sheet, and no primary SiFli source for these assignments was found. Signal names, counts, and physical assignments below must not be treated as verified.

Module declaration and implementation checklist¶

A module declaration should identify its base allocation and each supported extension map, for example M2, M2 + M2xM, or M2 + M2xN + M2xA. It should state the number of M2-form connectors implemented, their category, the implemented optional functions, and any mutually exclusive modes.

Before adopting this draft, verify:

• Whether the proposed connector footprint, card outline, retention hardware, and insertion orientation meet the applicable M.2 requirements.
• The number, placement, and category of M2-form connectors on the module and carrier.
• All multiplexed functions selected by the module, including any shared SDIO1/SDIO2, PDM, SWD (debug-UART vs. touch interrupt/reset), or CAN routing.
• Module-specific I/O voltage, current, reset, boot, and power-sequencing requirements.
• Whether a claimed M2xM MIPI, RGB, DVP, PDM, or I2S function is supported simultaneously or only as an alternate mode.
• Carrier-side requirements for CAN transceivers, USB protection, TF-card power/detect, display power, audio amplification, and external PHYs.

Last updated: 2026-10-10