Attachments (0)
Nordic Case Info
  • Case ID: 337647
Options

Compile error when using PWM on nRF54L15 (_P_pwms_IDX_0_VAL_channel undeclared)

tf_tdm

Hi,

I'm trying to get the PWM to work to operate a vibrator connected to the nRF54L15 PDK. I'm basing my activity on lesson4 - pwm as I'm also new to Zephyr (but experienced with nrf52).

The configuration part succeeds, but then the compilation fails with the following error:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
main.c:26:64: error: 'vibrator_P_pwms_IDX_0_VAL_channel' undeclared here (not in a function)
26 | static const struct pwm_dt_spec pwm_vibrator = PWM_DT_SPEC_GET(vibrator);
/home/me/ncs/zephyr/include/zephyr/devicetree.h:4888:9: note: in definition of macro 'DT_CAT7'
4888 | a1 ## a2 ## a3 ## a4 ## a5 ## a6 ## a7
| ^~
/home/me/ncs/zephyr/include/zephyr/devicetree/pwms.h:136:9: note: in expansion of macro 'DT_PHA_BY_IDX'
136 | DT_PHA_BY_IDX(node_id, pwms, idx, cell)
| ^~~~~~~~~~~~~
/home/me/ncs/zephyr/include/zephyr/devicetree/pwms.h:208:9: note: in expansion of macro 'DT_PWMS_CELL_BY_IDX'
208 | DT_PWMS_CELL_BY_IDX(node_id, idx, channel)
| ^~~~~~~~~~~~~~~~~~~
/home/me/ncs/zephyr/include/zephyr/drivers/pwm.h:261:28: note: in expansion of macro 'DT_PWMS_CHANNEL_BY_IDX'
261 | .channel = DT_PWMS_CHANNEL_BY_IDX(node_id, idx), \
| ^~~~~~~~~~~~~~~~~~~~~~
/home/me/ncs/zephyr/include/zephyr/drivers/pwm.h:328:34: note: in expansion of macro 'PWM_DT_SPEC_GET_BY_IDX'
328 | #define PWM_DT_SPEC_GET(node_id) PWM_DT_SPEC_GET_BY_IDX(node_id, 0)
| ^~~~~~~~~~~~~~~~~~~~~~
/home/me/srcs/main.c:26:48: note: in expansion of macro 'PWM_DT_SPEC_GET'
26 | static const struct pwm_dt_spec pwm_vibrator = PWM_DT_SPEC_GET(vibrator);
| ^~~~~~~~~~~~~~~
/home/me/srcs/main.c:26:64: error: 'vibrator_P_pwms_IDX_0_VAL_period' undeclared here (not in a function)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

This is my overlay:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/ {
vibrator: vibrator {
compatible = "pwm-servo";
pwms = <&pwm20 0 PWM_USEC(5) PWM_POLARITY_NORMAL>;
min-pulse = <PWM_USEC(1)>;
max-pulse = <PWM_USEC(5)>;
status = "okay";
};
};
&pinctrl {
pwm20_default_custom: pwm20_default_custom {
group1 {
psels = <NRF_PSEL(PWM_OUT0, 0, 13)>;
nordic,invert;
};
};
};
&pwm20 {
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

This is my basic prj.conf:

Fullscreen
1
2
3
CONFIG_PWM=y
CONFIG_LED=y
CONFIG_LED_PWM=y
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

And this is my basic main.c (I removed some unrelated parts so don't mind line numbers in the error messages):

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <stdint.h>
#include <zephyr/kernel.h>
#include <zephyr/device.h>
#include <zephyr/drivers/pwm.h>
#define PWM_VIB DT_ALIAS(vibrator)
#define PWM_PERIOD_NS 100000000
#define PWM_DUTY_CYCLE 1400000
static const struct pwm_dt_spec pwm_vibrator = PWM_DT_SPEC_GET(PWM_VIB);
void main(void) {
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

If I remove the line where I declare `pwm_vibrator` there's no more compilation error.

How can I make this work ?

All is built with `west build -b nrf54l15pdk@0.8.1/nrf54l15/cpuapp`

I'm using the toolchain 2.8.0 and nRF Connect SDK 2.8.0 on a Debian system.

Edit: I'd like to add that I tried to run the example's solution itself and ended up with the same issue.

I've cloned ncs-inter on commit 0b2e2e2, built in ncs-inter/v2.8.x-v2.7.0/l4/l4_e2_sol with 'west build -b nrf54l15pdk@0.8.1/nrf54l15/cpuapp' on SDK+toolchain 2.8.0 and obtained the same kind of error, i.e.:

/workdir/zephyr/include/zephyr/device.h:92:41: error: '__device_dts_ord_DT_N_NODELABEL_servo_P_pwms_IDX_0_PH_ORD' undeclared here (not in a function)

This was on my own variation of nrf-docker where I built the image for toolchain/SDK 2.8.0, so it's quite reproducible.

Parents
  • 0

    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. 

    Fullscreen
    1
    2
    3
    4
    / {
    aliases {
    vibrator = &vibrator;
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Regards,
    Elfving
  • 0 in reply to Elfving

    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:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    pwmleds {
    compatible = "pwm-leds";
    vibrator: vibrator {
    pwms = <&pwm20 0 PWM_USEC(5) PWM_POLARITY_NORMAL>;
    status = "okay";
    };
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    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.

  • 0 in reply to tf_tdm

    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

Reply
  • 0 in reply to tf_tdm

    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

Children
No Data
Terms of service