PWM with Zephyr on RT1020

Deepa-khatri2588 — Thu, 28 May 2026 17:44:27 GMT

I am working on a custom board based on the MIMXRT1021xxxxx (using the NXP MCUXpresso SDK under Zephyr RTOS). I am migrating a high-performance motor tension reel application from a standard FreeRTOS SDK implementation over to Zephyr, and I am hitting a critical blocker regarding the FlexPWM2 (Submodule 3, Channel A) peripheral clock behavior.

The Problem:

I am trying to command the torque dynamically

In FreeRTOS, the application works perfectly: the module maintains a constant frequency/tension holding loop without dropping out.
In Zephyr, the moment all operating system threads fall into an idle or sleep state (causing the ARM Cortex-M7 core to execute a Wait-for-Interrupt WFI instruction), the entire register space for FlexPWM2 Submodule 3 drops to 0 or freezes. The moment an event occurs or a thread wakes up, the registers temporarily recover, but the power/clock-saving "pauses" are completely breaking our motor control loop, resulting in a loss of torque and erratic brake behavior.

I have disabled the high-level OS Power Manager (CONFIG_PM=n), meaning the operating system isn't dynamically shutting down peripheral rails. It appears that the master clock source or the IPG peripheral clock tree feeding FlexPWM2 is automatically scaling down or clock-gating when the CPU idles.

What is the definitive, ideal initialization sequence to ensure a FlexPWM sub-module's clock source remains strictly pinned ON across all Run, Wait, and Doze states?
How can we cleanly change the duty cycle dynamically at runtime without causing glitch pulses or desynchronizing the shadow register buffer transfers (LDOK / MCTRL)?
Is it possible to completely decouple the FlexPWM clock gating from the CPU core's sleep states on the RT1020, or do we have to resort to a hardware workaround like FlexIO?

Current Configuration Details:

1. prj.conf (Power Management disabled, Clocks forced open)

# Disable standard power management to keep peripheral clocks wide open
CONFIG_PM=n
CONFIG_PM_DEVICE=n
CONFIG_CLOCK_CONTROL=y

# Standard PWM Driver activation
CONFIG_PWM=y

2. app.overlay (Devicetree Mapping with low-power overrides)

&iomuxc {
    pinmux_motor_pwm: pinmux_motor_pwm {
        group0 {
            /* Routes Pad 6 (GPIO_AD_B0_06) to FlexPWM2 Module 3 Channel A */
            pinmux = <&iomuxc_gpio_ad_b0_06_flexpwm2_pwma3>;
            drive-strength = "r0-6";
            slew-rate = "fast";
            bias-pull-up;
            nxp,speed = "150-mhz";
        };
    };
};

&flexpwm2_pwm3 {
    status = "okay";
    pinctrl-0 = <&pinmux_motor_pwm>;
    pinctrl-names = "default";
    clocks = <&ccm IMX_CCM_PWM_CLK 0 0>;
    
    /* Intended to force the counter to stay alive when CPU idles */
    run-in-wait;
    nxp,prescaler = <1>; 
};

3. Current Runtime Configuration (Using standard Zephyr API)

/* Initializing to safe zero-torque baseline on boot */
pwm_set_cycles(pwm_dev, 1, 12499, 12499, PWM_POLARITY_INVERTED);

/* Dynamic Runtime Torque Shift via Web Callback */
void set_motor_torque(int8_t level) {
    uint32_t pulse = (level > 0) ? 5500 : 12499;
    
    // This call works when threads are hot, but fails during OS idle pauses
    pwm_set_cycles(pwm_dev, 1, 12499, pulse, PWM_POLARITY_INVERTED);
}

I have even attempted bare-metal register overrides targeting CCM_CCGR4 (setting bits 24-25 to 0x3 to force the clock gate open continuously) and manually strobing MCTRL |= (1 << 3) for an immediate shadow latch, but reading the registers via volatile pointers still returns 0 whenever the kernel goes quiet.

Any insights on how to force the FlexPWM clock tree to remain active independently of the core state would be greatly appreciated!

Thank you.

Re: PWM with Zephyr on RT1020

Gavin_Jia — Fri, 29 May 2026 03:34:42 GMT

Hi @Deepa-khatri2588 ,

Thanks for your interest in NXP MIMXRT series!

The first thing I would correct is the PWM channel index. Your pinmux routes GPIO_AD_B0_06 to FLEXPWM2_PWMA3, which is channel A of submodule 3. In Zephyr’s pwm_mcux.c, channel 0 maps to kPWM_PwmA and channel 1 maps to kPWM_PwmB. Therefore your calls should use channel 0, not channel 1.

Zephyr’s nxp,imx-pwm binding supports run-in-wait and run-in-debug, and the MCUX PWM driver maps these properties to pwm_config.enableWait and pwm_config.enableDebugMode. Please keep these properties in the flexpwm2_pwm3 node.
For runtime torque updates, keep the period and polarity unchanged and only update the pulse width. This allows the Zephyr MCUX driver to use PWM_UpdatePwmDutycycle() followed by PWM_SetPwmLdok(), instead of stopping and reconfiguring the submodule.

If the PWM still stops only when the kernel becomes idle, this indicates the issue is related to WFI/WAIT-mode clock handling. CONFIG_PM=n disables Zephyr PM policy/device PM, but does not necessarily prevent the CPU idle path from executing WFI. As a diagnostic test, keep the CPU out of idle with a temporary high-priority busy thread. If the PWM then becomes stable, we should focus on the SoC WAIT-mode clock/CCM/GPC configuration or apply the i.MX RT low-power workaround path.

Best regards,
Gavin