initial pulse while starting a PWM application

[PM Bubblynet]

Hi,

A short summary, while using the app_PWM on our application I noticed an initial pulse on the PWM pin, its a 3V 1ms pulse that happens about 1 sec after powering on the nRF52832... 

The PWM configuration and initializations code is quite standard:

int main(void)

{
    initialize();
    // Initializing the PWM instance in main() function
    ret_code_t err_code;
    app_pwm_config_t pwm1_cfg = APP_PWM_DEFAULT_CONFIG_1CH(1000L, ON_OFF_LED);
    pwm1_cfg.pin_polarity[1] = APP_PWM_POLARITY_ACTIVE_LOW;
    err_code = app_pwm_init(&PWM1,&pwm1_cfg,pwm_ready_callback);
    app_pwm_enable(&PWM1);
    while ( app_pwm_channel_duty_set(&PWM1, 0, MIN_LIGHT_INTENSITY) == NRF_ERROR_BUSY);
    APP_ERROR_CHECK(err_code);

    execution_start(start);

Is there something I need to configure / disable / initialize on the PWM or the Startup sequence so I don't get this initial pulse? 

[PM Bubblynet]

The good news is: I found the "problem":

PM Bubblynet said:

pwm1_cfg.pin_polarity[1] = APP_PWM_POLARITY_ACTIVE_LOW;

that should be:

pwm1_cfg.pin_polarity[0] = APP_PWM_POLARITY_ACTIVE_LOW;

The bad news is that now all the logic behind my usage of the PWM is reversed... this was a question we had few weeks ago: https://devzone.nordicsemi.com/f/nordic-q-a/40002/pwm-library-issues/156496#156496 

so before I rewrite all the logic of my application, is there any way to keep current implementation with:

pwm1_cfg.pin_polarity[0] = APP_PWM_POLARITY_ACTIVE_HIGH;

Without getting this initial pulse? I tracked down this to the app_pwm_enable(&PWM1);

it doesn't help to invert 

while ( app_pwm_channel_duty_set(&PWM1, 0, MIN_LIGHT_INTENSITY) == NRF_ERROR_BUSY);

And

app_pwm_enable(&PWM1);

I tried:

int main(void)

{
    initialize();
    // Initializing the PWM instance in main() function
    ret_code_t err_code;
    app_pwm_config_t pwm1_cfg = APP_PWM_DEFAULT_CONFIG_1CH(1000L, ON_OFF_LED);
    pwm1_cfg.pin_polarity[0] = APP_PWM_POLARITY_ACTIVE_LOW;
    err_code = app_pwm_init(&PWM1,&pwm1_cfg,pwm_ready_callback);
    while ( app_pwm_channel_duty_set(&PWM1, 0, MIN_LIGHT_INTENSITY) == NRF_ERROR_BUSY);
    app_pwm_enable(&PWM1);
    
    APP_ERROR_CHECK(err_code);

    execution_start(start);

But didn't help, when executing 

app_pwm_enable(&PWM1);

I get that initial pulse anyways...

[Einar Thorsrud]

Hi,

The GPIO output pin is initially configured based on the pin polarity. So when you call app_pwm_init() with the polarity configuration set to APP_PWM_POLARITY_ACTIVE_LOW this will set the pin high. It will not change state until you call app_pwm_channel_duty_set(). If you want the default state to be low, you should use APP_PWM_POLARITY_ACTIVE_HIGH.

I don't follow what you mean by logic being reversed. If you want to keep the same scale for duty cycle after changing polarity you could set the duty cycle as (100 - duty_cycle).

[PM Bubblynet]

Hi,

The question is not about polarity... its about an unwanted/ unexpected initial pulse... in short, there is an initial pulse when enabling a PWM even when set:  app_pwm_channel_duty_set(&PWM1, 0, 1000), as I mentioned I tried:

PM Bubblynet said:

int main(void) { initialize(); // Initializing the PWM instance in main() function ret_code_t err_code; app_pwm_config_t pwm1_cfg = APP_PWM_DEFAULT_CONFIG_1CH(1000L, ON_OFF_LED); pwm1_cfg.pin_polarity[0] = APP_PWM_POLARITY_ACTIVE_LOW; err_code = app_pwm_init(&PWM1,&pwm1_cfg,pwm_ready_callback);
while ( app_pwm_channel_duty_set(&PWM1, 0, MIN_LIGHT_INTENSITY) == NRF_ERROR_BUSY); app_pwm_enable(&PWM1); APP_ERROR_CHECK(err_code); execution_start(start);

And it still has that initial pulse... so it looks like the app_pwm_channel_duty_set dont work until the app_pwm_enable is called?

About the logic being reversed, the initial code had a bug: instead of setting polarity on channel 0 it was setting the polarity on channel 1... that is not in use... I didn't catch that one until now... so all my dimming logic was written with the default polarity LOW... if I change the polarity now to HIGH I would need to rewrite the dimming logic, anyways... my question is: is there a way to keep the default active polarity (LOW) without that initial pulse? It looks like the app_pwm_channel_duty_set dont work if used before app_pwm_enable... in other words it seems we cant set the duty cycle and then enable the PWM?

[Einar Thorsrud]

I was not commenting on the problem where you mixed up the channels, as you wrote that you had solved it. Everything in my previous answer related to the initial pulse.

What I attempted to describe was that the initial pulse is because during initialization the output pin is set to high if the pin polarity is configure APP_PWM_POLARITY_ACTIVE_LOW (and vise versa). It keeps that state until you configure a duty cycle. What you are seeing is not a bug, but is the behavior you should expect with the code you are using. Therefore I mentioned how you can get the behaviour (I think) you want by simply reversing the polarity in the initialization and reversing the duty cycle in your call to app_pwm_channel_duty_set(). That way you will not get the initial pulse.

[PM Bubblynet]

Hi,

When you say

Einar Thorsrud said:

simply reversing the polarity in the initialization and reversing the duty cycle in your call to app_pwm_channel_duty_set()

what it means is that I would need to reverse all my calls to app_pwm_duty_set()... in other words, I would need to reverse the whole dimming logic... thats what I meant...

Einar Thorsrud said:

It keeps that state until you configure a duty cycle. What you are seeing is not a bug, but is the behavior you should expect with the code you are using.

thats my question, so lets see, I do the configuration:

app_pwm_config_t pwm1_cfg = APP_PWM_DEFAULT_CONFIG_1CH(1000L, ON_OFF_LED);

Then set polarity:

pwm1_cfg.pin_polarity[0] = APP_PWM_POLARITY_ACTIVE_LOW;

Then initialization:

err_code = app_pwm_init(&PWM1,&pwm1_cfg,pwm_ready_callback);

Then I set the duty cycle:

while ( app_pwm_channel_duty_set(&PWM1, 0, 1000) == NRF_ERROR_BUSY);

And finally I enable the PWM:

app_pwm_enable(&PWM1);

And then the PWM is at 100%? shouldn't the set instruction set the PWM to 0%? and when enabling the PWM should be 0%?

[Einar Thorsrud]

Hi,

There is a problem with the code you described in your last post, which is that you should call app_pwm_enable() before you call app_pwm_channel_duty_set(). Calling it the other way around causes the library to misbehave. This is unfortunately not documented as far as I can see and not obvious. There is also a problem that you set the duty cycle to 1000, which is not in the valid range (0 - 100).

You could update the code to be like this:

app_pwm_config_t pwm1_cfg = APP_PWM_DEFAULT_CONFIG_1CH(1000L, ON_OFF_LED);
pwm1_cfg.pin_polarity[0] = APP_PWM_POLARITY_ACTIVE_LOW;
err_code = app_pwm_init(&PWM1,&pwm1_cfg,pwm_ready_callback);
app_pwm_enable(&PWM1);
while ( app_pwm_channel_duty_set(&PWM1, 0, 100) == NRF_ERROR_BUSY);

In this case the pin state will be like the following:

• After reset before the pin is configured it will be the default state (disconnected input) = high impedance.
• After executing line 3 the pin will be configured as an output pin and set to the non-active state - high in this case.
• After executing line with the duty cycle is set to 100%, the pin should stay in the active state - low in this case.

So in this case you get the 1 ms pulse you have described and that is expected.

If you do the trick I mentioned you would have something like this instead. In that case you will not see any pulse:

app_pwm_config_t pwm1_cfg = APP_PWM_DEFAULT_CONFIG_1CH(1000L, ON_OFF_LED);
pwm1_cfg.pin_polarity[0] = APP_PWM_POLARITY_ACTIVE_HIGH;
err_code = app_pwm_init(&PWM1,&pwm1_cfg,pwm_ready_callback);
app_pwm_enable(&PWM1);
while ( app_pwm_channel_duty_set(&PWM1, 0, 100-100) == NRF_ERROR_BUSY);

[PM Bubblynet]

Hi Einar,

Thanks for the info, very useful indeed, and just to clarify, I used 1000 because I also edited the PWM driver library and set the range 0 to 1000 to have better control of the PWM on a logarithmic scale thats quite important in lighting, actually I might even go to 0 to 10000... in lighting the 0% to 10% its quite important and difficult to manage due to the non linear response from our eyes...