How to start pwm sequence after particular time delay of gpio event?

[RAM_MS]

I am working on an application where I need to start pwm sequence after particular delay (accurate delay of multiple of 100us).

I am quite new to nordic environment.

Here is my code . Can please guide me what is wrong here??

#define    Period    20000 //20ms

const nrf_drv_timer_t TIMER_LED = NRF_DRV_TIMER_INSTANCE(0);

APP_PWM_INSTANCE(PWM1,1); 

static int gpio_flag =0;

void pwm_update(void)
{
      uint32_t value;
      value = duty_1;
      ready_flag = false;
      /* Set the duty cycle - keep trying until PWM is ready... */
      
      

      while ((app_pwm_channel_duty_set(&PWM1, 0, value))&(app_pwm_channel_duty_set(&PWM1, 1, value)) == NRF_ERROR_BUSY);
 
      /* ... or wait for callback. */
      while (!ready_flag);
      APP_ERROR_CHECK(app_pwm_channel_duty_set(&PWM1, 1, value));
      APP_ERROR_CHECK(app_pwm_channel_duty_set(&PWM1, 0, value));

}


void in_pin_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
   gpio_flag =1;
   nrf_drv_timer_enable(&TIMER_LED);

   
}

void timer0_handler(nrf_timer_event_t event_type, void* p_context)
{
  switch (event_type)
    {
        case NRF_TIMER_EVENT_COMPARE0:
             timer_flg =1;
             nrf_drv_timer_clear(&TIMER_LED);
             gpio_flag=0;
             pwm_update();
            break;

        default:
            //Do nothing.
            break;
    }
}


void timer_init(void)
{
    uint32_t time_us = 500; 
    uint32_t time_ticks;
    uint32_t err_code = NRF_SUCCESS;

    nrf_drv_timer_config_t timer_cfg = NRF_DRV_TIMER_DEFAULT_CONFIG;
    err_code = nrf_drv_timer_init(&TIMER_LED, &timer_cfg, timer0_handler);
    APP_ERROR_CHECK(err_code);

    time_ticks = nrf_drv_timer_us_to_ticks(&TIMER_LED, time_us);
    nrf_drv_timer_compare(
         &TIMER_LED, NRF_TIMER_CC_CHANNEL0, time_ticks, true);

    
}

[Karl Ylvisaker]

Hello,

I am quite new to nordic environment.

Welcome! Please do not hesitate to ask if you should have any questions.

I am working on an application where I need to start pwm sequence after particular delay (accurate delay of multiple of 100us).

Could you show me the entirety of your main.c code?
Right now I do not see where you setup your gpio for triggering the enabling of the timer, so I am not sure that the timer is ever started, for instance.

Could you also elaborate on what behavior you are seeing, and how this differs from what you would expect? Does the device reset for example, or is it just that 'nothing' is happening, for example?

Best regards,
Karl

[RAM_MS]

Hello Karl,

Karl Ylvisaker said:

Right now I do not see where you setup your gpio for triggering the enabling of the timer, so I am not sure that the timer is ever started, for instance.

void in_pin_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
   gpio_flag =1;
   nrf_drv_timer_enable(&TIMER_LED);

   
}

Karl Ylvisaker said:

Could you also elaborate on what behavior you are seeing, and how this differs from what you would expect? Does the device reset for example, or is it just that 'nothing' is happening, for example?

I am not getting the delay I am expecting.

I think I have done some wrong configuration in linking to timer from gpio interrupt routine. 

Best regards,
Ram

[RAM_MS]

Hello Karl,

Karl Ylvisaker said:

Oh, I see now - you should not do an APP_ERROR_CHECK on the return value from nrf_drv_pwm_simple_playback, as mention in its API Reference it returns the address of the task you should trigger to start the sequence (this address should be equal to the one you got from the addres_get function in the PPI setup).

You mean to say that what Get from  pwm_task_addr= nrf_drv_pwm_task_address_get(&m_pwm0,NRF_PWM_TASK_SEQSTART0);

Same should use here  like pwm_task_addr=nrf_drv_pwm_simple_playback(&m_pwm0, &seq, 1,NRF_DRV_PWM_FLAG_STOP | NRF_DRV_PWM_FLAG_START_VIA_TASK);

{
//ppi init part
compare_event_addr = nrf_drv_timer_task_address_get(&PWM_DELAY_TIMER,NRF_TIMER_CC_CHANNEL0);
pwm_task_addr =  nrf_drv_pwm_task_address_get(&m_pwm0,NRF_PWM_TASK_SEQSTART0);

err_code = nrf_drv_ppi_channel_assign(ppi_channel_2, compare_event_addr,pwm_task_addr);
}

{
// pwm init part 
pwm_task_addr=nrf_drv_pwm_simple_playback(&m_pwm0, &seq, 1,NRF_DRV_PWM_FLAG_LOOP | NRF_DRV_PWM_FLAG_START_VIA_TASK);
}

Thanks Karl It is working now .

Many Many Thanks .

But now there is a problem.

1)the timing is not correct .Here I am attaching the snapshot of it 

From the picture you can clearly see that the delay time is more than 1ms .

How can I make it exact??

Best regards,
 Ram

[Karl Ylvisaker]

Hello again, Ram

RAM_MS said:

You mean to say that what Get from  pwm_task_addr= nrf_drv_pwm_task_address_get(&m_pwm0,NRF_PWM_TASK_SEQSTART0);

Same should use here  like pwm_task_addr=nrf_drv_pwm_simple_playback(&m_pwm0, &seq, 1,NRF_DRV_PWM_FLAG_STOP | NRF_DRV_PWM_FLAG_START_VIA_TASK);

Yes, you could use the address returned by nrf_drv_pwm_simple_playback as the input to the PPI connection.

RAM_MS said:

Thanks Karl It is working now .

Many Many Thanks .

But now there is a problem.

Great, I am happy to hear that we have progressed closer to the desired functionality.

RAM_MS said:

From the picture you can clearly see that the delay time is more than 1ms .

How can I make it exact??

This does indeed not look correct - that is quite the added delay, more than 200 µs it seems.
Could you clarify exactly what you are scoping here with the blue and yellow line? I assume it is the inputted PWM and the resulting delayed PWM output, but it would be good if you could confirm / specify this.

To debug this we will need to find out where in the chain of events this delay is introduced.
Could you try this again with different delays, so we may see if there is an issue with the timer configuration for instance?
Alternatively, as a debugging measure, you could change to have the TIMER CC event connected to a pin toggle TASK, so we may verify that the timer is producing the correct delay.
I look forward to hearing what you observe when you test this!

Best regards,
Karl

[RAM_MS]

Hello Karl,

Karl Ylvisaker said:

This does indeed not look correct - that is quite the added delay, more than 200 µs it seems.
Could you clarify exactly what you are scoping here with the blue and yellow line? I assume it is the inputted PWM and the resulting delayed PWM output, but it would be good if you could confirm / specify this

Yes ,you assumed right .Yellow line is inputted PWM and blue line is delayed PWM output.

Karl Ylvisaker said:

To debug this we will need to find out where in the chain of events this delay is introduced.
Could you try this again with different delays, so we may see if there is an issue with the timer configuration for instance?

I tested with different delays that is 1ms ,2ms ,3ms etc .Every where the same added delay around 200 µs

coming.

Karl Ylvisaker said:

Alternatively, as a debugging measure, you could change to have the TIMER CC event connected to a pin toggle TASK, so we may verify that the timer is producing the correct delay.

I tested this and the output is attached here in below .

Here yellow line is inputted PWM and blue line is gpio toggle output .

Here you can clearly notice that 2ms timing is exact.

Best regards,
Ram

[Karl Ylvisaker]

Hello again Ram,

Thank you for the clarification and update.

RAM_MS said:

I tested with different delays that is 1ms ,2ms ,3ms etc .Every where the same added delay around 200 µs

coming.

RAM_MS said:

I tested this and the output is attached here in below .

RAM_MS said:

Here yellow line is inputted PWM and blue line is gpio toggle output .

Here you can clearly notice that 2ms timing is exact.

This is great steps for the debugging - well done!
So, it it clear that the timer toggles the GPIOTE at a precise interval, and that the delay is added elsewhere. 

Could you check whether you are receiving any EVENTS_SEQSTARTED events in your pwm event handler?
To find out how long it takes from the PWM start task is triggered until the SEQSTARTED event is received you could use the nrf_timer_cc_read function in the timer's event handler for the CC event, and then again in the PWM handler for the SEQSTARTED event - then subtract the initial value and the added delay to find the difference.

Could you show me your code as it is right now? I will take a look and see if I can spot what might be adding the delay.
Did you change it so that you are providing the pwm_start_task_address returned from the nrf_drv_simple_playback call to the PPI initialization?

Best regards,
Karl

[RAM_MS]

Hello Karl,

Karl Ylvisaker said:

Could you show me your code as it is right now? I will take a look and see if I can spot what might be adding the delay.

Here I attached the code for your reference.

0310.main.zip

Karl Ylvisaker said:

Did you change it so that you are providing the pwm_start_task_address returned from the nrf_drv_simple_playback call to the PPI initialization?

Yes ,I changed .

Please verify once is it right in provided code.

Karl Ylvisaker said:

Could you check whether you are receiving any EVENTS_SEQSTARTED events in your pwm event handler?
To find out how long it takes from the PWM start task is triggered until the SEQSTARTED event is received you could use the nrf_timer_cc_read function in the timer's event handler for the CC event, and then again in the PWM handler for the SEQSTARTED event - then subtract the initial value and the added delay to find the difference.

I am trying to test this .I will update you soon.

Best regards,
Ram

[Karl Ylvisaker]

RAM_MS said:

Here I attached the code for your reference.

Thank you for sharing the code.
Looking through the code I notice that you are initializing the GPIOTE as a low-accuracy input, in the line:

nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);

Could you try to change this to high accuracy, by changing the configuration parameter to true?
I do not really think that this should matter, since the PORT event will be triggered just as fast as the IN_EVENT, but it would be good to have ruled out as well.

I also recommend that you define your pins using the NRF_GPIO_PIN_MAP macro instead of just writing their pin number, but this is a very minor comment on my part and it will work just as well with the pins number directly.

RAM_MS said:

Yes ,I changed .

Please verify once is it right in provided code.

I do not see this change implemented in the code you just shared - it seems like this might be the code that was used to test the TIMER's accuracy.
I see that you have created a global variable to store the pwm_task_addr returned by the nrf_drv_pwm_simple_playback function call, so I assume you will be using that variable to store it, and pass it to the PPI assign function.
I would urge you to add a check to the PPI init function that checks if the pwm_task_addr and gpiote_task_addr variables has been set before you proceed to pass them to the PPI peripheral.
You will also need to run the GPIOTE and PWM init functions before the PPI init function, to make sure that the addresses has been updated before they are connected through the PPI.

RAM_MS said:

I am trying to test this .I will update you soon.

Great, I look forward to hearing what you find out! :) 

Best regards,
Karl

[RAM_MS]

Hello Karl,

Karl Ylvisaker said:

I do not see this change implemented in the code you just shared - it seems like this might be the code that was used to test the TIMER's accuracy.

Sorry ,You are right I shared the code that was used to test the TIMER's accuracy.

Karl Ylvisaker said:

I see that you have created a global variable to store the pwm_task_addr returned by the nrf_drv_pwm_simple_playback function call, so I assume you will be using that variable to store it, and pass it to the PPI assign function.

Yes ,you are right I am using that variable to store it and pass it to the PPI assign function.

Karl Ylvisaker said:

You will also need to run the GPIOTE and PWM init functions before the PPI init function, to make sure that the addresses has been updated before they are connected through the PPI.

Thank you so much Karl ,this was the problem in my code after arranging this correcting now I am able to get exact TIMING Delay .

Now ,another problem arises actually .

For testing purpose I generated inputting PWM signal from PIN NO 11( that is PWM_PIN 11) in the code you might seen it and giving it to (PIN_IN 22). 

But in real case the inputting PWM will come from outside .

So for create this scenario I created inputted PWM signal from a different NRF52 DK .

And what I observed is my Generated PWM Signal is Shifting with time.

For your reference I am attaching the video of it.

what could be the reason for this problem ?

As always Yellow one is INPUTTED PWM SIGNAL and Blue one is my OUTPUT PWM .

And you can clearly see that blue line is slowly shifting to left .

Best regards,
Ram

 

[Karl Ylvisaker]

Hello again,

RAM_MS said:

Thank you so much Karl ,this was the problem in my code after arranging this correcting now I am able to get exact TIMING Delay .

No problem at all, Ram - I am happy to hear that this resolved the added delay issue!

RAM_MS said:

Sorry ,You are right I shared the code that was used to test the TIMER's accuracy.

RAM_MS said:

Yes ,you are right I am using that variable to store it and pass it to the PPI assign function.

RAM_MS said:

As always Yellow one is INPUTTED PWM SIGNAL and Blue one is my OUTPUT PWM .

Thank you for clarifying these things.

RAM_MS said:

For testing purpose I generated inputting PWM signal from PIN NO 11( that is PWM_PIN 11) in the code you might seen it and giving it to (PIN_IN 22). 

But in real case the inputting PWM will come from outside .

So for create this scenario I created inputted PWM signal from a different NRF52 DK .

And what I observed is my Generated PWM Signal is Shifting with time.

For your reference I am attaching the video of it.

That is very strange indeed. Perhaps there is something amiss with the sequence looping.

Could you share the newest version of the code - the code you ran when you observed this - so I may see if I can spot any potential explanation for this?

Best regards,
Karl

[RAM_MS]

Hello Karl,

Karl Ylvisaker said:

I am happy to hear that this resolved the added delay issue!

I am really happy that we patiently progress up to this stage.

And Thank you a lot .

Karl Ylvisaker said:

That is very strange indeed. Perhaps there is something amiss with the sequence looping.

Could you share the newest version of the code - the code you ran when you observed this - so I may see if I can spot any potential explanation for this?

For your reference I am attaching code here.

7384.main.zip

As earlier I said for testing purpose I generated 1st in the same DK in PWM_PIN(11).

But for now I commented this part by commenting pwm1_init();

And giving INPUTTED PWM Signal from Different DK in PIN_IN (22);

Best regards,
Ram

[Karl Ylvisaker]

RAM_MS said:

I am really happy that we patiently progress up to this stage.

And Thank you a lot .

No problem at all, Ram - I am happy to help!

RAM_MS said:

As earlier I said for testing purpose I generated 1st in the same DK in PWM_PIN(11).

But for now I commented this part by commenting pwm1_init();

And giving INPUTTED PWM Signal from Different DK in PIN_IN (22);

Thank you for clarifying this.

RAM_MS said:

For your reference I am attaching code here.

I do not immediately see the reason for why the phase shift would be happening, but I suspect that it might be because the PPI channels are left enabled throughout the run of the application, so that there might be happening a brief stopping and re-starting of the waveform generation, or similar, causing the phase shift.
Could you try to implement the stopping / disabling of the GPIOTE pin, TIMER instance and PPI channels when the PWM is successfully started, like we talked about earlier?

By the way, you can change your GPIOTE_CONFIG_IN_SENSE_LOTOHI(true); back to false again - since this was not the cause of the added delay earlier.

I also notice that you are still not using the pwm start task address returned from the nrf_drv_pwm_simple_playback call, since it is overwritten by the call to nrf_pwm_task_addr_get in the ppi_init - this should not matter though, since they should point to the same address - but I point it out to avoid any confusion since you have stated earlier that it is this return address that is being used.

Best regards,
Karl