Board/SDK: FRDM-RW612, NXP-Zephyr v4.3.0
Configured on-board RGB LED (GPIO0=Blue, GPIO1=Red, GPIO12=Green) as pwm-leds on CTIMER0, channels 0/1/2 respectively, using IO_MUX_CT0_MAT0_OUT_IO0, IO_MUX_CT0_MAT1_OUT_IO1, IO_MUX_CT0_MAT2_OUT_IO12 in a shared pinctrl-0 group. Ran a test app cycling duty cycle on all three channels.
Red and Green LEDs PWM correctly (confirmed with Saleae logic analyzer — clean waveforms on GPIO1 and GPIO12). Blue LED (GPIO0/MAT0) stays completely off — logic analyzer shows a flat line, no toggling at any duty cycle (0–100%). Digital GPIO (non-PWM) toggle on GPIO0 works fine,
Only CTIMER0 MAT0 channel fails to output PWM; MAT1/MAT2 on the same timer instance work.
What we need:
#include
/ {
pwm_outputs {
compatible = "pwm-leds";
pwm_gpio0: pwm_gpio0 {
pwms = <&ctimer0_pwm 0 PWM_KHZ(1) PWM_POLARITY_NORMAL>;
};
pwm_gpio1: pwm_gpio1 {
pwms = <&ctimer0_pwm 1 PWM_KHZ(1) PWM_POLARITY_NORMAL>;
};
pwm_gpio12: pwm_gpio12 {
pwms = <&ctimer0_pwm 2 PWM_KHZ(1) PWM_POLARITY_NORMAL>;
};
};
aliases {
pwm-gpio0 = &pwm_gpio0;
pwm-gpio1 = &pwm_gpio1;
pwm-gpio12 = &pwm_gpio12;
};
};
ctimer0_pwm: &ctimer0 {
compatible = "nxp,ctimer-pwm";
status = "okay";
clk-source = <5>;
clocks = <&clkctl1 MCUX_CTIMER0_CLK>;
#pwm-cells = <3>;
mode = <0>;
prescale = <0>;
pinctrl-0 = <&pinmux_ctimer0_pwm>;
pinctrl-names = "default";
};
&pinctrl {
pinmux_ctimer0_pwm: pinmux_ctimer0_pwm {
group0 {
pinmux = <
IO_MUX_CT0_MAT0_OUT_IO0
IO_MUX_CT0_MAT1_OUT_IO1
IO_MUX_CT0_MAT2_OUT_IO12
>;
slew-rate = "normal";
};
};
};
Hello,
Hope you are doing well. Could you please helps us confirm what application are you taking as a base?
Also, can you clarify how are you measuring the pwm signals? Specific pin of the FRDM for each pwm.
Best Regards,
Ricardo
I created a custom project based on zephyr/samples/basic/rgb_led using NXP-Zephyr v4.3.0.
When I build the project with v4.3.0, ctimer0_pwm 0 does not work. However, when I build it with v4.4.1.1 or later, ctimer0_pwm 0 works as expected.
I used a Saleae logic analyzer to capture the PWM signals during testing and confirmed the difference between the two versions.
Could this be a bug in v4.3.0?