This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Own PWM device with own board not working

Hello,

I have an own hardware using nRF5340. So I created first an own board in the device tree. I took the definition of the nRF5340 development board and simply removed all the connectors, button, leds that were not on the pure processor. That seems to work. As this definition should be used for other similar boards, I keept all the status at disabled.

In an overlay file of my current project I changed the status now to ok:

/ {
   soc {

         peripheral@50000000 {
                     pwm0: pwm@21000 {
                           status = "okay";
                     };
         };
   };
};

In the generated zephyr.dts I see then, that the status is ok. So that works. But I understand some device tree documentation that the following should also work:

/ {
    &pwm0 {
       status = "okay";
    };
}:

But pressing then Run CMake in SES I got the errors:

Error: nrf5340_ces_app.dts.pre.tmp:616.9-14 syntax error
FATAL ERROR: Unable to parse input tree
CMake Error at C:/ncs/v1.8.0/zephyr/cmake/dts.cmake:225 (message):

Even not so nice I could live for the moment with the first aproach. But would be nice to get knowledge about the problem and how to make it right.

My main problem is with my beeper. I want to use the pwm moduls together with pin 16 of port 0. So I define a beeper (in the overlay file) as

        beepernode{
             beeper: beepersnode {
                    pwms = < &pwm0 16 >;
                    };
        };

Run CMake doesn't give an error and I see this part in zephyr.dts

Following the documentation and the blinky_pwm example I try to use my beeper with

    pwm = DEVICE_DT_GET(DT_PWMS_CTLR(DT_NODELABEL(beeper)));
    if (!device_is_ready(pwm))
    {
            return;
    }

But building is not working and I get the error

4> In file included from C:/ncs/v1.8.0/zephyr/include/toolchain/gcc.h:66,
4>                  from C:/ncs/v1.8.0/zephyr/include/toolchain.h:50,
4>                  from C:/ncs/v1.8.0/zephyr/include/kernel_includes.h:19,
4>                  from C:/ncs/v1.8.0/zephyr/include/kernel.h:17,
4>                  from C:/ncs/v1.8.0/zephyr/include/zephyr.h:18,
4>                  from ../BA_Beschlag.cpp:1:
4> ../BA_Beschlag.cpp: In function 'void main()':
4> C:/ncs/v1.8.0/zephyr/include/device.h:81:39: error: '__device_dts_ord_DT_N_S_beepernode_S_beepersnode_P_pwms_IDX_0_PH_ORD' was not declared in this scope
4> C:/ncs/v1.8.0/zephyr/include/toolchain/common.h:124:26: note: in definition of macro '_DO_CONCAT'
4> C:/ncs/v1.8.0/zephyr/include/device.h:81:31: note: in expansion of macro '_CONCAT'
4> C:/ncs/v1.8.0/zephyr/include/device.h:233:37: note: in expansion of macro 'DEVICE_NAME_GET'
4> C:/ncs/v1.8.0/zephyr/include/device.h:247:34: note: in expansion of macro 'DEVICE_DT_NAME_GET'
4> ../BA_Beschlag.cpp:32:11: note: in expansion of macro 'DEVICE_DT_GET'

I tried several changes but can't find my error.

What do I have to do to get my beeper working as pwm device?

Erwin

Parents
  • Hi,

     

    Seems like you are lacking the compatible part of the overlay:

    / {    
        beepernode {
            compatible = "pwm-leds";
            beeper: beepersnode {
                    pwms = < &pwm0 16>;
                    label = "beeper node LED";
            };
        };
    };

     

    Could you try this and report back?

     

    Kind regards,

    Håkon

  • Now I get the linker failure

    undefined reference to `__device_dts_ord_8'

  • here's my overlay, matched to the LEDs on the nrf52dk (file boards/nrf52dk_nrf52832.overlay):

    / {
            leds {
                    compatible = "gpio-leds";
                    red_led: led_1 {
                            gpios = <&gpio0 17 0>;
                            label = "RGB red channel";
                    };
                    green_led: led_2 {
                            gpios = <&gpio0 18 0>;
                            label = "RGB green channel";
                    };
                    blue_led: led_3 {
                            gpios = <&gpio0 19 0>;
                            label = "RGB blue channel";
                    };
            };
            pwmleds {
                    compatible = "pwm-leds";
    
                    red_pwm_led: led_pwm_0 {
                            pwms = <&pwm0 17>;
                            label = "Red PWM LED";
                    };
    
                    green_pwm_led: led_pwm_1 {
                            pwms = <&pwm0 18>;
                            label = "Green PWM LED";
                    };
    
                    blue_pwm_led: led_pwm_2 {
                            pwms = <&pwm0 19>;
                            label = "Blue PWM LED";
                    };
            };
            beepernode {
                    compatible = "pwm-leds";
                    beeper: beepersnode {
                            pwms = < &pwm0 20>;
                            label = "beeper node";
                    };
            };
            aliases {
                    red-pwm-led = &red_pwm_led;
                    green-pwm-led = &green_pwm_led;
                    blue-pwm-led = &blue_pwm_led;
            };
    };
    
    &pwm0 {
            status = "okay";
            ch0-pin = <17>;
            ch1-pin = <18>;
            ch2-pin = <19>;
            ch3-pin = <20>;
    };
    

     

    This is the overlay for the zephyr/samples/basic/rgb_led sample to work with the DK, where I just added your beepernode as a 4th channel on the pwm0 instance.

     

    Kind regards,

    Håkon

  • I changed now my example to really use a LED that is connected to Pin24 of Port 0. So no Beeper, even praktically it shouldn't be a real difference.

    The overlay file is:

    / {
            leds {
                    compatible = "gpio-leds";
                    red_led: led_1 {
                            gpios = <&gpio0 24 0>;
                            label = "RGB red channel";
                    };
            };
            pwmleds {
                    compatible = "pwm-leds";
                    red_pwm_led: led_pwm_0 {
                            pwms = <&pwm0 24>;
                            label = "Red PWM LED";
                    };
            };
            aliases {
                    red-pwm-led = &red_pwm_led;
            };
    };
    &pwm0 {
            status = "okay";
            ch0-pin = <24>;
    };
    My main function (in a c++ file, so with ending cpp) is now simple:
    #include <zephyr.h>
    #include <device.h>
    #include <drivers/pwm.h>
    const struct device* pPwm;
    void main(void)
    {
        pPwm = DEVICE_DT_GET(DT_NODELABEL(red_pwm_led));
        if (!device_is_ready(pPwm))
        {
                return;
        }
        if (pwm_pin_set_usec(pPwm, DT_PWMS_CHANNEL(DT_NODELABEL(red_pwm_led)), 200, 100, DT_PWMS_FLAGS(DT_NODELABEL(red_pwm_led))))
        {
                return;
        }
    }
    running CMake works but when I build all I got the warning
    undefined reference to `__device_dts_ord_14'
    So it still doesn't work.
  • Here's my test project, added cpp as well:

    rgb_led.zip

    Note: I'm testing with another board, but that should not matter as long as you rename the .overlay to your board.

     

    Kind regards,

    Håkon

Reply Children
  • Your project works also on my hardware. Great. Through comparing I figured out that I had disabled the pwm driver in my nrfConnect project configuration. That might lead to the error. I will check.

    So principally I have what I need.

    But according my understanding the driver doesn't provide an interface to start or stop the output. I have to configure it always anew? And with a PWM value of 0% the LED is practically off. But this reconfiguration is somewhat expencive. Our device runs on battery and we also will use the sleep mode.

    Therefore I guess I need a nice start and stop funktion. As the source code of the driver is available I hope to be able to write correct source code on my own. Or do you have a hint?

    Best regards
    Erwin

  • Hi Erwin,

     

    You are right, there's no stop/disable implemented, but there is some logic in the PWM port for this specific scenario:

    https://github.com/nrfconnect/sdk-zephyr/blob/v2.7.0-ncs1/drivers/pwm/pwm_nrfx.c#L200-L232

     

    Setting it to 0 or 100, should stop the PWM if no other instances are currently running.

    Could you try this and see if this works on your end?

     

    Kind regards,

    Håkon

  • Hi Håkon,

    in the meantime I've found this Setting to 0 / 100. And it works. I still have to look into more Details if this is good enough. Power consumption is a very important aspect in our development and I wouldn't be surprised when there is a difference between "disable PWM" and "configure to 0%". But it will take some time until I reach this step.

    At the Moment I have still issues with the usage of Zephyr Driver with device tree.

    Do you even know how I could close this ticket? Should I simply press the "Verify Answer" button? In the meantime I have several ticket and they are all in waiting state, even for me they are closed.

    Best regards
    Erwin

  • Hi Erwin,

     

    ErwinCes said:
    in the meantime I've found this Setting to 0 / 100. And it works. I still have to look into more Details if this is good enough. Power consumption is a very important aspect in our development and I wouldn't be surprised when there is a difference between "disable PWM" and "configure to 0%". But it will take some time until I reach this step.

    I'm glad to hear that it worked!

    ErwinCes said:

    At the Moment I have still issues with the usage of Zephyr Driver with device tree.

    Do you even know how I could close this ticket? Should I simply press the "Verify Answer" button? In the meantime I have several ticket and they are all in waiting state, even for me they are closed.

    If you feel that the ticket is answered, I can manually close it for you, but if you verify one answer, it will also be automatically closed.

     

    Kind regards,

    Håkon

Related