MSPM0G3507: Single-wire communication in safety

If you set the INENA bit in the IOMUX, you can see the current state of that (input or output) GPIO.

Driverlib doesn't make it easy, but after configuring the pin you can do something like:

> IOMUX->SECCFG.PINCM[pincmIndex] |= IOMUX_PINCM_INENA_ENABLE;

Hi Marton,

Yes, this is supported.

On MSPM0G3507, the input buffer can be enabled through the IOMUX INENA bit so that software can read the actual logic level present on the pad, even when the pin is configured for GPIO output operation. This is the correct approach if you want to implement an open-drain style single-wire interface and also read back the bus state.

For example, after configuring the pin, you can enable the input buffer with:

IOMUX->SECCFG.PINCM[pincmIndex] |= IOMUX_PINCM_INENA_ENABLE;

Then read the pin using the normal GPIO input read path, for example:

bool busHigh = (DL_GPIO_readPins(GPIOx, GPIO_PIN_x) != 0U);

For single-wire open-drain communication, I would not recommend repeatedly switching the pin between output mode and input mode unless the protocol really requires it. A better approach is to keep the pin configuration fixed as open-drain / high-Z-on-1, enable the input buffer, and control the bus as follows:

Transmit 0: drive the pin low
Transmit 1: release the pin, external pullup brings the line high
Receive:    release the pin and read the input state

This avoids unnecessary runtime IOMUX reconfiguration and reduces the chance of timing or contention issues.

A few important hardware notes:

• Use an external pull-up sized for the required bus speed and capacitance.

• Make sure all devices on the single-wire bus are open-drain/open-collector style. No device should actively drive the line high.

• If using the MSPM0 ODIO/5-V-tolerant open-drain pins, the hardware development guide notes that ODIO pins require an external pull-up, so we recommend a series resistor between the pin and pull-up path, with 270 Ω shown as the suggested value.

• The MSPM0G3507 datasheet defines open-drain capable signal types, including OD and IOD, and describes IOD as input, output, or simultaneous input/output with open-drain behavior.

For a safety application, this is possible, but the safety case depends on the system-level implementation, not only the GPIO capability. If this communication is safety-relevant, I would recommend adding diagnostics such as:

• readback after driving low to detect failure to pull the bus low,

• readback after releasing the line to detect stuck-low faults,

• timeout detection for a stuck bus,

• CRC/checksum on frames,

• sequence counter or alive counter,

• defined safe state on communication loss,

• bus contention analysis,

• external pullup/open/short fault analysis.

If this is an automotive-style single-wire network, also consider whether a dedicated LIN physical layer is more appropriate. TI’s MSPM0 G-Series hardware guide describes LIN as a common single-wire automotive interface and shows typical MSPM0 + LIN transceiver implementations, which provide a more robust physical layer than a direct GPIO-only bus. Hope this helps!

-Brian