VRC_CTRL Clarification

[kumamon]

Hello NXP Support,

I would like to ask some questions on S32K3's VRC_CTRL (PTE13).

(1) RM mentions VRC_CTRL is direct signal, could you please check the understanding/question in the following table (red font)?

ALTx	OBE	IBE	VRC_CTRL	Question
GPIO	Disabled	Disabled	Enabled	VRC_CTRL will take effect, right?
GPIO	Disabled	Enabled	Enabled	VRC_CTRL will still take effect, right?
GPIO	Enabled	Not Care	Enabled	Who will take effect?

(2) If we configure PTE13 as GPIO + OBE Enabled + Output Level Low, will the VRC_CTRL negative feedback mechanism be broken because VRC_CTRL is treated as error signal and now maybe GPIO and VRC_CTRL are driving the pin at the same time?

(3) In NXP MCAL, as long as I configure PTE13 as PG_VRC_CTRL_OUT, OBE will be automatically set by function Port_Ipw_SetOnlyOutputMode(), is it an issue of MCAL?

(4) How to test VRC_CTRL feedback mechanism , what waveform is expected during which condition?

(5) Why is MSCR141 documented as "Not Supported" in RM?

Thanks.

BR

[PavelL]

Hello @kumamon ,

I think the main misunderstanding is that VRC_CTRL is being treated as a regular SIUL2/GPIO output.

VRC_CTRL is a direct output of the PMC last-mile regulator. When the external ballast-transistor supply option is used, the PMC monitors the V15 domain and adjusts VRC_CTRL, which is connected to the base of the external NPN transistor. This forms a closed analog feedback loop. Therefore, VRC_CTRL is not controlled through the normal GPIO output data registers.

For this reason, the GPIO ALTx, IBE and OBE combinations in the table are not applicable to the VRC_CTRL function:

1. IBE only controls the digital input buffer and has no role in the V15 regulator feedback loop.

2. VRC_CTRL should not be configured or forced as a GPIO output while it is used by the last-mile regulator. In particular, setting a GPIO output level to Low is not the correct way to disable or control the regulator.

3. The last-mile regulator is controlled by the PMC, including the PMC_CONFIG[LMBCTLEN] field and the initialization sequence documented in the device-specific PMC chapter.

4. VRC_CTRL is an analog control signal rather than a digital status output. Consequently, there is no single fixed waveform that applies to all designs. Its voltage depends on the external transistor, V15 load, supply voltage, external capacitance and operating mode. For validation, V15 and VRC_CTRL should be measured together during startup and under load changes. The expected result is that V15 remains within its specified operating range while VRC_CTRL adjusts the external transistor as required.

5. MSCR141 is documented as “Not Supported” because PTE13/VRC_CTRL uses a direct connection from the PMC rather than the normal SIUL2 output-multiplexing path. Therefore, MSCR141 must not be used to control the VRC_CTRL function.

Regarding Port_Ipw_SetOnlyOutputMode(), the fact that this function is called does not by itself prove that the PMC regulator is affected.

Please also note that the reset behavior is derivative-specific. For example, the S32K3x8 (and S32K356) PMC has a device-specific CONFIG reset value of 0x00000083, so the last-mile regulator configuration is enabled after reset. This must not be generalized from older S32K3 derivatives where LMBCTLEN may need to be enabled explicitly.

Best regards,

Pavel

[kumamon]

Hello Pavel,

Thanks a lot for your detailed answer.

VRC_CTRL should not be configured or forced as a GPIO output while it is used by the last-mile regulator. In particular, setting a GPIO output level to Low is not the correct way to disable or control the regulator.

What will happen if VRC_CTRL is enabled and OBE is also enabled at the same time? Maybe a intermediate level will be present on PTE13?

Where can I find some diagram to describe the combined driving path from both direct signal and SIUL2 output-multiplexing?

The following is my measurement. You can see when VRC_CTRL is enable, GPIO output can have some impact to the PTE13.

For validation, V15 and VRC_CTRL should be measured together during startup and under load changes.

How to trigger the load change, is it by switching the frequency of the core?

MSCR141 is documented as “Not Supported” because PTE13/VRC_CTRL uses a direct connection from the PMC rather than the normal SIUL2 output-multiplexing path. Therefore, MSCR141 must not be used to control the VRC_CTRL function.

I didn't quite understand here, at least GPIO141 can be used when VRC_CTRL is disabled, why does RM just mention MSCR141 is not supported?

Actually I can access MSCR141 from debugger, and I can switch the settings there. 

Regarding Port_Ipw_SetOnlyOutputMode(), the fact that this function is called does not by itself prove that the PMC regulator is affected.

Sorry, I didn't get your point here.

Actually this is the main reason I asked this question, following code will be generated when I configure PTE13 PinMode as PG_VRC_CTRL_OUT in MCAL Port module.

#define SIUL2_0_PORT141_PG_VRC_CTRL_OUT (PORT_ONLY_OUTPUT_MODE)
Port_Ipw_SetOnlyOutputMode() will be called and “OBE” bit will set in this function.​

I think it maybe a MCAL bug, PG_VRC_CTRL_OUT mode enables OBE by mistake.

Could you please help to check?

Do you think that configuring it to GPIO + PORT_PIN_HIGH_Z + PORT_PIN_LEVEL_NOTCHANGE can be a workaround, in this case, MSCR141 of PTE13 can be guaranteed to be 0 (OBE = 0)?

Best regards

Kumamon

[PavelL]

Hello @kumamon ,

Thank you for the measurements. They confirm that setting MSCR141[OBE] = 1 enables the digital output driver and allows the GPIO level to influence the VRC_CTRL node. Enabling the GPIO output driver while the PMC last-mile regulator is active is not a supported configuration and can disturb V15 regulation.

This does not necessarily indicate an MCAL driver defect. PTE13/VRC_CTRL is a special-purpose pin that requires application-specific handling. The generic Port driver enables OBE when an output mode is requested, but it cannot determine whether the PMC regulator and the external ballast-transistor circuit are being used.

Your proposed workaround is appropriate, provided that the resulting configuration leaves MSCR141[OBE] = 0:

• Use PORT_PIN_HIGH_Z.
• Use PORT_PIN_LEVEL_NOTCHANGED.
• Verify MSCR141[OBE] after Port_Init().
• Do not subsequently configure PTE13 as a digital output while VRC_CTRL is active.

The essential requirement is to keep the digital output buffer disabled.

Best regards,

Pavel

[kumamon]

Hello Pavel,

Thanks for the answer.

The generic Port driver enables OBE when an output mode is requested.

Do you know which setting other than PG_VRC_CTRL_OUT in the following figure introduces the "output mode"? Sorry, but I still feel MCAL Port maps the PG_VRC_CTRL_OUT to output mode by mistake.

For validation, V15 and VRC_CTRL should be measured together during startup and under load changes.

How to trigger the load change, is it by switching the frequency of the core?

Thanks.

BR/Kumamon

[PavelL]

Hello @kumamon ,

The configuration shown in your screenshot appears to be correct.

Regarding the load-change measurement, this was only an optional suggestion for evaluating the regulator response. It is not required to verify the VRC_CTRL configuration. If such a test is desired, changing the CPU workload while keeping the clock configuration unchanged is generally easier to interpret than changing the core frequency.

Best regards,

Pavel