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

RA2E1: Duty cycle initialization for GPT timer

Hi,

I'm using RA2E1 microcontroller with FSP 4.0.0 and I'm having some issues with the first cycle of a GPT outputs (2 pins configurated). I want the duty cycle of both outputs to be different, but it seems that the first cycle always applies the same duty cycle (the one configured in the FSP) for both outputs.

My configuration:

- r_gpt timer channel 6, Triangle-Wave-Symmetric PWM

- Pin configuration: GTIOCA OR GTIOCB in order to have independent duty cycles

- Output signal configuration:

I want GTIOCA to have a duty cycle of 85u and GTIOCB to have a duty cycle of 133u.

I'm trying to do that via SW, but the first cycle of the output signal always has a duty cycle of 50 for both outputs.

My code:

R_GPT_Open(&g_pwm_ctrl, &g_pwm_cfg);

R_GPT_DutyCycleSet(&g_pwm_ctrl, 85U, GPT_IO_PIN_GTIOCA);

R_GPT_DutyCycleSet(&g_pwm_ctrl, 133U, GPT_IO_PIN_GTIOCB);

R_GPT_Start(&g_pwm_ctrl);

And the result I'm having is:

The signal I want to obtain would be as follows:

Is there anyway I can configure the first cycle the way I want or the first cycle always shares the same duty cycle for both outputs?

Best regards,

Itxaso.




[locked by: Sai (SWF) at 12:50 (GMT 0) on 2 Feb 2023]
  • Hi Itxaso,

    Thanks for reaching out to Renesas Engineering Community.

    As stated in FSP documentation

    The period and duty cycle are updated after the next counter overflow after calling R_GPT_PeriodSet() or R_GPT_DutyCycleSet(). To force them to update before the next counter overflow, call R_GPT_Reset() while the counter is running.

    After the first counter overflow everything seems normal. Could you try calling R_GPT_Reset before starting the timer ?

    I hope it helps.

    Regards,

    AZ

  • Hi AZ,

    Thanks for your response.

    I've tried calling R_GPT_Reset as you suggested but the result remains the same.

    I've also tried setting the output pin to disabled in the FSP and calling R_GPT_OutputEnable() after calling R_GPT_DutyCycleSet(), but I can't seem to make it work.

    Regards,

    Itxaso.

  • Hi Itxaso,

    Could you try to set duty cycle percent to 0 ?

    Let us know if it helps.

    Regards,

    AZ

  • Hi AZ,

    I've tried it but the first cycle still doesn't works as wanted. As I've configurated one output as inital level high, the first cycle with duty cycle set to 0 fixes the output of one pin to 1 and the other pin to 0:

    Is there anyway I can configure the first cycle the way I need? It seems that FSP is lacking the option to configure both pins in an independent way. 

    I've tried several things:

    1. Set output to disable, open GPT timer, change duty, reset timer, change output to enable:

                 first cycle remains the same

    2. Open GPT timer, change duty, reset timer, close timer and reopen it:

                 closing and reopening the timer resets it to the first configuration, no duty change is reapplied

    3. Set output to disable, open GPT timer, change duty, reset timer, start timer, stop timer, change output to enable

                 No change. Maybe the start-stop code sequence has not enough time to be applied? 

    Regards,

    Itxaso.

  • Hi AZ,

    I've managed to make work the third previous option by configuring a counter of t=period in order to run the timer with the first configuration for a cycle and enabling the output after that:

    Set output to disable

    open GPT timer

    change duty

    reset timer

    start timer

    while (cont <= period) cont++;

    stop timer

    change output to enable

    I'm guessing it's not the ideal way to do it. I'm still wondering if there's anyway to configure both outputs in a independent way.

    Regards,

    Itxaso.

  • I think the issue is related to buffer transfer. By default the driver has enabled single buffer operation and when using R_GPT_DutyCycleSet, it is updating only the buffer registers(GTCCRC/E) instead of GTCCRA/B and these buffer value are transferred at the next undeflow to GTCCRA/B.

    You can directly update the correspoding GTCCRA/B regsiters before starting the GPT channel. This should resolve the issue.

  • Hi VS,

    Thank you for your answer, it worked!

    Best regards,

    Itxaso.

  • Hi Itxaso,

    We are glad that you solved your issue. Thanks for verifying the answers above. If you have any further questions let us know with a new post.

    Best regards,

    AZ