Port Pin getting spike when written with value LOW.

[ManuSharma]

Hi,
We are currently working with the NXP S32K132 controller, and during startup (after Power-On Reset), we are observing a voltage spike (High) on some port pins, even though we are explicitly setting their output level to LOW.

Issue Details:
We are configuring the following port pins in assembly code during early startup:

PTD14 (GPIO[110])
PTD15 (GPIO[111])
PTD17 (GPIO[113])
Despite setting these pins to LOW, we observe a short High-level spike immediately after reset, before the pin level stabilizes to LOW.

Current Initialization Sequence:
1. Retrieve GPDO (GPIO Data Output) address.
2. Write LOW level to the GPDO (i.e., set output to 0).
3. Retrieve MSCR (Multiplexed Signal Configuration Register) address.
4. Write configuration data to MSCR (set as 0x280000, which likely configures it as output, push-pull, no pull-up/down, etc.).

Observation:
The spike appears during Step 2, i.e., while writing LOW to the GPDO, even though we have not set the pin HIGH at any point.

Questions:
1. Is there any default output state or internal pull-up active immediately after Power-On Reset that could be causing the spike?

2. Is the order of operations correct, or should MSCR be configured before writing to GPDO to avoid glitching?

3. Is there a recommendation from NXP to avoid startup spikes on GPIOs configured as outputs?

We would appreciate any guidance or clarification to ensure clean, spike-free initialization on these output pins.

Thanks & Regards

Manu Sharma

[danielmartynek]

Hello @ManuSharma,

I'm not able to reproduce it on S32K312 EVB.

	IP_SIUL2->GPDO110 = 0;  /* PTD14 */
	IP_SIUL2->GPDO111 = 1;  /* PTD15 */
	IP_SIUL2->GPDO113 = 0;  /* PTD17 */

	IP_SIUL2->MSCR[110] = 0x00280000;
	IP_SIUL2->MSCR[111] = 0x00280000;
	IP_SIUL2->MSCR[113] = 0x00280000;

    for(;;)
    {
    }

I see PTD15 is driven high, whole PTD14 stays low (analog signal)

It looks to me like the spike to bias voltage during power up.

The spike follows VDD until the MCU becomes biased at ~0.7V.

Can you measure VDD along with the pins?

Regards,

Daniel

[ManuSharma]

Hello @danielmartynek,

Apologies for the delayed response — we were engaged with other activities.

We have observed additional behavior related to pin state spikes in various scenarios, particularly when waking up from Low Power Mode. Please find the details below:

Steps Followed:

1. Set the output value of the pin to LOW.

2. Entered Low Power Mode (Sleep/Standby).

3. Triggered wakeup from low power mode.

4. Observed a brief spike (HIGH) on the pins before they returned to LOW.

Expected Behavior:
The software should retain the pin state during Low Power Mode and restore it immediately after wakeup — i.e., the pin should remain LOW throughout.

Actual Behavior:
After wakeup, a 3ms spike (HIGH) is observed, after which the pin returns to LOW.

Debugging Observation:
We enabled the "PortPin Pull Keeper" setting, and after doing so, the spike was no longer observed.

As per the reference manual, the Pull Keeper is designed to retain the pin state while the MCU is in Standby mode.

Request for Clarification:
We would like your input on the following points:

1. Is enabling the "PortPin Pull Keeper" a valid and recommended solution in this case?
→ Our understanding was that the MCU should retain the pin state during standby even without this setting enabled.

2. Could the spike be due to the pin being in a floating/uncontrollable/high-impedance state during the transition if yes then can let us know what might be the reason for this?

3. Aside from the Pull Keeper setting, are there any other configurations we should verify to ensure stable pin behavior during Low Power Mode?

We appreciate your insights and clarification on this matter.

Thanks & Regards,
Manu Sharma

[danielmartynek]

Hello @ManuSharma,

Even without PadKeeping enabled, the MCU retains output states during Standby mode.

However, the purpose of PadKeeping is to ensure that the state of the pins is preserved across the wake-up reset - not just during Standby, but also through the transition back to RUN mode.

The "PortPin Pull Keeper" option enables PadKeeping locally for individual pads.

PadKeeping must also be enabled globally in the MCU driver for Standby mode (DCM.DCMRWF1[STANDBY_IO_CONFIG] == 0)

After Wake-Up Reset:

Reconfigure the pins from their default reset state to the configuration they had before entering Standby mode (via the PORT driver).
After that, disable PadKeeping globally in the MCU driver (power mode configuration).

This sequence ensures that the pins retain their intended state throughout the entire low-power cycle.

1. Yes

2. Yes, the MCU goes through a system reset.

3. No

Regards,

Daniel

[ManuSharma]

Hello @danielmartynek 

I did not understand about the "wake-up reset".

Do you mean when SW comes out from standby mode due to wakeup source it got reset internally and set the default level to the port pins?

If yes then does MCU perform this operation("wake-up reset") on its on.

Thanks & Regards

Manu Sharma

[danielmartynek]

Hi @ManuSharma,

The transition from STANDBY to RUN is always through a system reset.

Yes, the MCU performs it on it own.

https://www.nxp.com/docs/en/application-note/AN13414.pdf

[ManuSharma]

Hello @danielmartynek,

We have one more point to clarify regarding the pad type differences listed in the S32K312 IOMUX sheet. As per the documentation, the following pins have different pad types:

• PTD17 (GPIO113) – c40esf3_p_io_standard_mv

• PTD15 (GPIO111) – c40esf3_p_io_standard_plus_mv

• PTD14 (GPIO110) – c40esf3_p_io_standard_plus_mv

Questions for Clarification:

1. What is the technical difference between c40esf3_p_io_standard_mv and c40esf3_p_io_standard_plus_mv pad types?

2. Since PTD15 and PTD14 use the c40esf3_p_io_standard_plus_mv pad type, is this the reason why spikes are observed on these two pins?

3. Do we need to enable "PortPin Pull Keeper" for PTD15 and PTD14 to avoid spikes during transitions (e.g., startup or wakeup), specifically because of their pad type?

We would appreciate your clarification on the above points to ensure proper configuration and signal stability.

Thanks & Regards,
Manu Sharma

[danielmartynek]

Hello @ManuSharma,

1.

Please refer to the S32K3xx Datasheet for details on pad types.
Specifically, see:

Table 25 – GPIO DC Electrical Specifications, 5.0V (4.5V – 5.5V)

Table 26 – 5.0V (4.5V – 5.5V) GPIO Output AC Specifications

These tables outline the electrical characteristics and timing behavior of the GPIOs based on pad type.

2.

I was unable to reproduce the issue on my EVB.
The behavior you're seeing could be due tot he external circuitry connected to the pins, or
Electromagnetic interference (EMI).

Note that the pins are in High-Z mode.
If you connect them to VSS via a weak external pull-down, you should not observe the spike.

3.

The "PortPin Pull Keeper" is active only during wake-up.
It ensures that the output retains its state (e.g., LOW) throughout the wake-up reset, until pad keeping is disabled. However, any other type of reset (e.g., power-on reset, software reset) will reset the pin states.

Regards,

Daniel