Should the I/O of a pin not automatically determined by the pin mux tool?

[durga_choudhury]

On the 'pin mux tool' of S32 Design studio (v 3.6.2 if it matters), when I assign a pin to a protocol (as opposed to GPIO) it still expects me to assign the direction of the pin (I or O) explicitly; they are all assigned as 'input' by default.

Should the tool not do this automatically? For example, the data_out of JTAG is always output; why should I have to do this manually?

What I am more worried is that I am not using the tool correctly; it is supposed to do it automatically if configured correctly which I have not done.

[durga_choudhury]

Thank you for your support.

[PetrS]

Hi,

no, the Pins tool does not (and is not supposed to) automatically set pin “direction” (I/O) for non‑GPIO alternate functions.

The “Direction” field you see primarily applies when the pin is muxed as GPIO. When you select an alternate/peripheral function (SPI, I2C, JTAG, etc.), the effective direction is governed by the peripheral hardware/driver, not by the GPIO direction setting.

BR, Petr

[durga_choudhury]

Hi @PetrS 

Thank you for the feedback. That makes sense. So, to rephrase your answer to make sure I got it right:

The 'direction' field is ignored in all functionality when the pin is not acting as a GPIO line. Is that right?

On a related question, there is a third state 'not specified'; I suppose this is the same as 'Input_Output' in S32DS v2.2 from which I am importing the project. I suppose this also only applies to GPIO functionality and it means that the pin can be read from and written to without changing configuration. Am I right?

Another question is, I don't see a way to tristate a pin in the pin mux tool. Is that possible?

[PetrS]

Hi,

this is my understanding

1) Direction field generation
In the latest Pins tool, when a pad is muxed as GPIO, the generated pin_settings_config_t will include a .direction member. When the pad is muxed to a peripheral alternate function, the .direction field is omitted, because the GPIO direction is irrelevant in that mode and the peripheral owns the signal direction.

2) “not specified” → High‑Z via PIDR 
For GPIO selection and “not specified” option, tool generates .direction = PORT_CI_PORT_PIN_HIGH_Z, which resolves into a high‑impedance configuration at init time. The driver will disable the input buffer via GPIOx_PIDR (Port Input Disable Register), so:
- Output driver is not enabled.
- Input buffer is disabled → the pad is high‑Z.
Practically, this is the tool’s way to express “leave the pin floating” (no drive, no sense) in generated code without you needing to do extra steps.

3) see above (2)
Any pin with GPIO mux and “not specified” will end up tri‑stated by virtue of PIDR settings (and no output driver enabled).

BR, Petr

[durga_choudhury]

Hello @PetrS 

Thank you for your reply; this is all making sense. However, I have one more follow up question:

Is it (not) possible to make a GPIO line bidirectional? For example, let's say I want to implement an I2C-like protocol entirely in software and want to use a bit-banged set of GPIO lines for this. How would I configure the 'SDA' line in this case?

I believe the 'input-output' configuration in the older S32DS for ARM v2.2 served this purpose, but I don't see that feature in the latest S32DS anymore.

[PetrS]

Hi,

for the I2C you will need open drain, and the device does not support open drain on all the pins. Only pins that are configured for a protocol that requires open-drain (e.g;, LPI2C, LPUART single-wire) will work in open-drain mode.

The easiest workaround could be to configure the pin as input, initialize output value in PDOR register as ‘0’ and then use register PDDR (Data Direction) to switch between levels (either Hi-Z or ‘0’ output). The only disadvantage is that you need to ensure that the output value in PDOR register is not set to ‘1’ by mistake because it would lead to short circuit.

BR, Petr

[durga_choudhury]

Thank you, @PetrS for the response. So my question basically is this:

If I want to have 'my own' bit-banged protocol that can have multiple transmitters, and I want to implement it with GPIOs that *can* be open-drained, do I need to write any code to put them in the open-drain state? (or is it that these pins are always open-drained and therefore nothing needs to be done?)

[PetrS · Accepted solution]

Hi,

As I wrote, the S32K1xx does not support open-drain output on GPIO pins, so there is no configuration option for this.
However, you can implement a workaround by setting the pin as an input, which places it in a high-impedance state and allows it to be pulled up externally (e.g., by an I²C pull-up resistor).
To drive the pin low when needed, initialize the output value in the PDOR register to ‘0’, and then use the PDDR (Data Direction) register to switch between states:
- Input mode → High impedance (Hi-Z), but pulled up
- Output mode → Logic ‘0

BR, Petr