Issue about PWM of NCS

RE: Issue about PWM of NCS

Hannibalhz — Fri, 20 Jun 2025 06:33:57 GMT

Hi Susheel

I would like to know this problem has any update?

Best regards,

Hannibal

RE: Issue about PWM of NCS

Susheel Nuguru — Wed, 28 May 2025 06:27:22 GMT

Yes, Hannibal, I meant to use three PWMs for testing. And it seemed like your device tree looks right.

RE: Issue about PWM of NCS

Hannibalhz — Mon, 26 May 2025 10:50:54 GMT

Hi Susheel

Thank you for your best supports. Do you mean using three PWMs? Then, do you think this way of writing the device tree is correct?

/ {
    aliases {
        led0 = &led0;
		led1 = &led1;
		led2 = &led2;
        red-pwm-led   = &led_r;
        green-pwm-led = &led_g;
        blue-pwm-led  = &led_b;
    };

    leds {
		compatible = "gpio-leds";
        led0: led_0 {
			gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
			label = "Red LED 0";
		};
		led1: led_1 {
			gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
			label = "Green LED 1";
		};
		led2: led_2 {
			gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
			label = "Blue LED 2";
		};
	};

    pwmleds {
        compatible = "pwm-leds";
        
        led_r: led_0 {
            pwms = <&pwm20 0 PWM_MSEC(20) PWM_POLARITY_NORMAL>;
            label = "Red LED";
        };
    
        led_g: led_1 {
            pwms = <&pwm21 0 PWM_MSEC(20) PWM_POLARITY_NORMAL>;
            label = "Green LED";
        };
    
        led_b: led_2 {
            pwms = <&pwm22 0 PWM_MSEC(20) PWM_POLARITY_NORMAL>;
            label = "Blue LED";
        };
    };
};

&pwm20 {
    status = "okay";
    pinctrl-0 = <&pwm20_default>;
    pinctrl-1 = <&pwm20_sleep>;
    pinctrl-names = "default", "sleep";
};

&pwm21 {
    status = "okay";
    pinctrl-0 = <&pwm21_default>;
    pinctrl-1 = <&pwm21_sleep>;
    pinctrl-names = "default", "sleep";
};

&pwm22 {
    status = "okay";
    pinctrl-0 = <&pwm22_default>;
    pinctrl-1 = <&pwm22_sleep>;
    pinctrl-names = "default", "sleep";
};


&pinctrl {
    pwm20_default: pwm20_default {
        group1 {
            psels = <NRF_PSEL(PWM_OUT0, 1, 4)>;   /* P1.04 -> LED_R */
        };
    };
    pwm20_sleep: pwm20_sleep {
        group1 {
            psels = <NRF_PSEL(PWM_OUT0, 1, 4)>;   /* P1.04 -> LED_R */
                    low-power-enable;
        };
    };

    pwm21_default: pwm21_default {
        group1 {
            psels = <NRF_PSEL(PWM_OUT0, 1, 5)>;   /* P1.05 -> LED_G */
        };
    };
    pwm21_sleep: pwm21_sleep {
        group1 {
            psels = <NRF_PSEL(PWM_OUT0, 1, 5)>;   /* P1.05 -> LED_G */
                    low-power-enable;
        };
    };

    pwm22_default: pwm22_default {
        group1 {
            psels = <NRF_PSEL(PWM_OUT0, 1, 6)>;   /* P1.06 -> LED_B */
        };
    };
    pwm22_sleep: pwm22_sleep {
        group1 {
            psels = <NRF_PSEL(PWM_OUT0, 1, 6)>;   /* P1.06 -> LED_B */
                    low-power-enable;
        };
    };
};




&uart20 {
    status = "disabled";
};

&uart30 {
    status = "okay";
};
/{
    chosen {
        zephyr,console = &uart30;
        zephyr,shell-uart = &uart30;
        zephyr,uart-mcumgr = &uart30;
        zephyr,bt-mon-uart = &uart30;
        zephyr,bt-c2h-uart = &uart30;
    };
};

Best regards,

Hannibal

RE: Issue about PWM of NCS

Susheel Nuguru — Wed, 21 May 2025 08:02:25 GMT

Hi Hannibal,

It is possible that there is a bug in PWM driver in this scenario. The thing is that this is only reproduced on nRF54 and I am unable to see such issues on nRF52. I need to spend more time on it and probably create an internal ticket to debug it to the hardware level. This might take time. But until then can you please try to see if you can change your firmware and devicetree to use three different pwm instances for three LEDs?

RE: Issue about PWM of NCS

Susheel Nuguru — Tue, 20 May 2025 12:06:54 GMT

Hi Hannibal,

I tried to debug this and use a lot of different ways to initialize the PWM and also use pwm_set_pulse_dt individually to set PWM but I can still see the other channels being impacted whenever we start or stop the PWM (brightness level 0->1 or 1->0). I need to spend more time to debug this.

RE: Issue about PWM of NCS

Susheel Nuguru — Tue, 20 May 2025 06:15:33 GMT

Hi Hannibal,

I reproduced the behavior and trying to debug it now. Will come back to you once I have some progress and new info to share with you.

RE: Issue about PWM of NCS

Hannibalhz — Mon, 19 May 2025 05:43:39 GMT

Hi Susheel

According to the latest test I conducted, this issue has nothing to do with the LED numbers. Because even after I changed it to this way, where only one channel is controlled, the problem still persists.

int main(void)
{
	const struct device *led_pwm;
	uint8_t led;

	led_pwm = DEVICE_DT_GET(LED_PWM_NODE_ID);
	if (!device_is_ready(led_pwm)) {
		LOG_ERR("Device %s is not ready", led_pwm->name);
		return 0;
	}

	if (!num_leds) {
		LOG_ERR("No LEDs found for %s", led_pwm->name);
		return 0;
	}

	while (1)
	{
			run_led_test(led_pwm, 0);
	}
}

You can use my code to conduct a test on the NRF54L15DK. Using a logic analyzer, it is quite easy to reproduce this problem.

Best regards,

Hannibal

RE: Issue about PWM of NCS

Susheel Nuguru — Fri, 16 May 2025 06:41:43 GMT

Hi Wang,

I think the whole issue here is that you are executing

	while (1)
	{
		// for (led = 1; led <= num_leds; led++) {
			run_led_test(led_pwm, 3);
		// }
	}

LED here is not just a number but it is the PWM channel index as specified in your overlay file like below

    pwms = <&pwm20 0 …>,   /* led index 0: RED  */
           <&pwm20 1 …>,   /* led index 1: GREEN*/
           <&pwm20 2 …>;   /* led index 2: BLUE */

So in the configuration config->num_leds == 3 which you have used right but the indices are

led_set_brightness(led_pwm, 0, brightness);  // RED
led_set_brightness(led_pwm, 1, brightness);  // GREEN
led_set_brightness(led_pwm, 2, brightness);  // BLUE

So your for loop should not start at led = 1 but should start at led =0

for (uint8_t led = 0; led < num_leds; led++) {
    run_led_test(led_pwm, led);
}

RE: Issue about PWM of NCS

Hannibalhz — Fri, 16 May 2025 04:01:23 GMT

update:

Today, I debugged and found that only the register configuration of one channel was set. However, the levels of the other two channels were actually flipped. Moreover, this phenomenon does not occur when using three channels; it only happens when using a single channel.