• State Verified Answer
  • Replies 4 replies
  • Subscribers 75 subscribers
  • Views 89 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 345896
Options

Options To Reduce PWM Power Consumption On nRF52811?

ntennies

We're using PWM on the nRF52811 to generate a 3.2 MHz clock needed by one of our peripherals, using the nrf_drv_pwm library in nRF5 SDK 17.1.0. We're seeing power consumption jump up by about 1.7 mA when PWM is enabled. Questions:

* Does that sound about right for a 3.2 MHz PWM clock, or should we expect lower power consumption?

* Are we correct that a lot of that is due to EasyDMA being automatically enabled in hardware when PWM is enabled.

* Are we correct that there is not a low-power configuration for the PWM peripheral controller?

* Are we correct that it's not possible to use the PWM peripheral controller without EasyDMA?

* Are we correct that the low-power PWM library is not capable of generating frequencies this high?

* Are there any other options available for generating a 3.2 MHz clock from the nRF52811 at lower power consumption?

Parents
  • 0
    Hello Nathan,
    Based on the current consumption you report the first question is what clock source are you using for as input for the PWM/peripheral clock. It sounds like you've configured HFXO as source, but you should probably use HFINT instead?
    EasyDMA is the only option, but not causing the current consumption you're seeing.
    Best regards
    Asbjørn
  • 0 in reply to Asbjørn

    Asbjørn,

    > It sounds like you've configured HFXO as source, but you should probably use HFINT instead?

    Thank you for your response, but I'm not sure what you are suggesting here, for the following reasons:

    * The nRF52811 PWM controller does not allow the selection of a clock source, to the best of my knowledge

    * In the nRF5 SDK architecture, nrf_drv_clock / nrfx_clock / SoftDevice handles enabling HFXO on-demand for peripherals that require it. We're not using any of those peripherals except BLE, and while the SoftDevice is enabled at this point in our code, BLE isn't initialized yet. So the HFXO should not be running.

    * nrf_drv_clock_hfclk_is_running() returns 0 if we call it immediately prior to measuring PWM power consumption.

    So I think HFXO is definitely not being used as a clock source for PWM in our case.

    > EasyDMA is the only option, but not causing the current consumption you're seeing.

    Why do you say that? There are many reports here that simply enabling a peripheral that uses EasyDMA increases power consumption by at least 1 mA, and that's been our experience with the nRF52840 as well. For instance, see EasyDMA current consumption 

  • +1 in reply to ntennies
    Hello Nathan,
    I've had a talk to others here and we come to the conclusion that the number you're seeing and measuring might actually be right as expected. It's just a high frequency and that doesn't allow for much time for the device to be in sleep to keep the accuracy. 64Mhz and DMA usage with DCDC and then switched into power down mode rarely, then you'd end up with the numbers you're seeing.
    There's a suggestion to try the sw_pwm with rtc, but this will probably sacrifice the accuracy you need for current consumption:

        sw_pwm: sw-pwm {
        compatible = "nordic,nrf-sw-pwm";
        status = "okay";
        generator = <&rtc1>;
        clock-prescaler = <0>;
        #pwm-cells = <3>;
    };

    Best regards
    Asbjørn
  • 0 in reply to Asbjørn

    Asbjørn,

    Thank you very much for checking into this further, and confirming my conclusions.

    For anyone else in this situation, I think one possible lower-power solution would be to switch to using a TIMER -> PPI -> GPIO solution -- see the GPIOTE example -- which I think eliminates the need for EasyDMA. Of course, maybe generating a clock using those three peripherals would consume enough power to offset the use of EasyDMA, but I'm going to give this a try and can report results back here.

    The only downside (for us, in this case) is that because you have to toggle the GPIO twice for each clock cycle, it effectively halves the base TIMER clock in half. On the nRF52811, the TIMER uses a 16 MHz base clock, so that means we're effectively using the TIMER to divide down an 8 MHz clock, and we can't divide an 8 MHz clock evenly to produce a 3.2 MHz clock. However, I've used this method to generate a 1.6 MHz clock on the nRF52811, and since we're considering switching to the nRF54L15 for this project, there is a TIMER instance on that MCU that uses a 32 MHz base clock.

Reply
  • 0 in reply to Asbjørn

    Asbjørn,

    Thank you very much for checking into this further, and confirming my conclusions.

    For anyone else in this situation, I think one possible lower-power solution would be to switch to using a TIMER -> PPI -> GPIO solution -- see the GPIOTE example -- which I think eliminates the need for EasyDMA. Of course, maybe generating a clock using those three peripherals would consume enough power to offset the use of EasyDMA, but I'm going to give this a try and can report results back here.

    The only downside (for us, in this case) is that because you have to toggle the GPIO twice for each clock cycle, it effectively halves the base TIMER clock in half. On the nRF52811, the TIMER uses a 16 MHz base clock, so that means we're effectively using the TIMER to divide down an 8 MHz clock, and we can't divide an 8 MHz clock evenly to produce a 3.2 MHz clock. However, I've used this method to generate a 1.6 MHz clock on the nRF52811, and since we're considering switching to the nRF54L15 for this project, there is a TIMER instance on that MCU that uses a 32 MHz base clock.

Children
No Data
Related
Terms of service