Compile error when using PWM on nRF54L15 (_P_pwms_IDX_0_VAL_channel undeclared)

RE: Compile error when using PWM on nRF54L15 (_P_pwms_IDX_0_VAL_channel undeclared)

Elfving — Fri, 13 Dec 2024 15:59:38 GMT

Great! Glad you got it solved, and shared your solution in case anyone else runs into the same thing.

Let us know if there is anything else.

Regards,

Elfving

RE: Compile error when using PWM on nRF54L15 (_P_pwms_IDX_0_VAL_channel undeclared)

tf_tdm — Fri, 13 Dec 2024 15:37:56 GMT

Thanks for your reply!

With help from a colleague, we identified a few issues on my end, hope this can help whoever ends up here in the future, me included:

- The board chosen does not exist for this exercise, i.e. doesn't have an overlay. It's because I was using the **p**dk instead of the **dk**. After changing to `-b nrf54l15dk`, I finally have all the proper definitions for the PWM module.

- As the example has parts about pwm-leds and others about pwm-servo, I thought they were interchangeable. They're not, the dts definition of a pwm-led compatible node or a pwm-servo compatible node are different.

Using this, at least this time the build works:

    pwmleds {
        compatible = "pwm-leds";
		vibrator: vibrator {
			pwms = <&pwm20 0 PWM_USEC(5) PWM_POLARITY_NORMAL>;
			status = "okay";
		};
	};

I managed to get a successful build with these changes, so it's already something. I don't see any signal on the pin, but I think I'll figure this out.

I wish Zepyhr devicetree config errors or overlays not found would be a bit more obvious than some obscure missing definitions in generated code, that makes it hard to progress.

RE: Compile error when using PWM on nRF54L15 (_P_pwms_IDX_0_VAL_channel undeclared)

Elfving — Fri, 13 Dec 2024 13:39:09 GMT

Hi,

My immediate thought on this question is that there is something dts and sysbuild related that is not explained or is not supported by this particular DevAcademy course. As you see on the right side here, we only have partial support for the nRF54L15 and NCS 2.8. Although this particular issue just seems to be dts related, just keep in mind that maybe not everything mentioned there will be supported in 2.8.

I am glad that you are checking out the DevAcademy and NCS though. Switching from nRF5 SDK is the right choice.

So the reason why they can just use the DT_ALIAS in the sample is because the board allready has that alias defined in its dts (aliases { ..}). Have you added that for the vibrator as well? If not, you could add that, though there are ofcourse other ways you could address this as well. The DevAcademy fundementals course explains these differences better than I can.

/ {
    aliases {
        vibrator = &vibrator;
    };

Regards,

Elfving