TMS320F28P659DK-Q1: Jitter using HRPWM in period mode

Hi Simone,

Doesnt look like jitter on the scope. Looks like two waveforms overlapping or running in continuous mode.

Did you take this scopeshot by stopping the scope plot or was it still running ?

Reason being that there are two distinct waveforms and not the same waveform going up and down

Hi Prarthan,
thanks for your reply, the graph on the oscilloscope was running.
The wave is actually the same in two different times, I attach other screens from the oscilloscope if I stop the acquisition instead.

I took a screenshot of two near period, when the signal is high. In the first you can see a duration of about 251ns, the next period, instead, has an higher duration:

If you don't stop the acquisition you can see the following image where you can see the different duration (7ns, seems about the duration of a tick):

It seems that the whole period is larger (compared to the previous, in the same trace I mean):

Best regars,

Simone

Simone,

Simone Coppola said:

The wave is actually the same in two different times

I didn't quite understand your question here. 
Please capture two cycles of same waveform in one shot and show the difference between times using cursor.

Simone Coppola said:

I took a screenshot of two near period, when the signal is high. In the first you can see a duration of about 251ns, the next period, instead, has an higher duration:

What is difference between two screenshots shown above ? 

Thanks

Hello,

I captured two cycle of the same waveform in one shot, here you can find the time difference:

The period is longer because it is longer the time when the signal is high:

When I say that the waveform is the same at two different times I mean that the square wave is generated with EPWM1 peripheral and the value of the configuration registers does not change but, as you can see in the screenshot, I found that sometimes the period changes. So, in the screenshot, the first cycle has a duration of 500ns and the second cycle has a duration of 508ns. The main difference is that, in the second cycle, the square wave is high for a longer time.

Thanks,

Simone

Hi Simone,

Understood, the configurations remain same but the output (period, duty) changes as measured on the scope.

Are you sure the period and compare values are never changed ? original example changes duty and period in the for loop

Also If the application has enabled high-resolution period control (HRPCTL[HRPE]=1), the duty cycle must not fall within the restricted range; otherwise, there can be undefined behavior on the ePWM output. Please make sure the min and max duty cycle restrictions are honoured

Thanks

Hi,

Yes, I verified what you suggested.
To do a check, I tried to modify the main of the example as follows and the problem is still present. You can try to execute it to reproduce the problem.

float32_t periodFineCustom;
float32_t count;
uint32_t compCount;
void main(void)
{
    uint16_t i = 0;

    //
    // Initialize device clock and peripherals
    //
    Device_init();

    //
    // Disable pin locks and enable internal pull ups.
    //
    Device_initGPIO();

    //
    // Initialize PIE and clear PIE registers. Disables CPU interrupts.
    //
    Interrupt_initModule();

    //
    // Initialize the PIE vector table with pointers to the shell Interrupt
    // Service Routines (ISR).
    //
    Interrupt_initVectorTable();

    //
    // Calling SFO() updates the HRMSTEP register with calibrated MEP_ScaleFactor.
    // HRMSTEP must be populated with a scale factor value prior to enabling
    // high resolution period control.
    //
    while(status == SFO_INCOMPLETE)
    {
        status = SFO();
        if(status == SFO_ERROR)
        {
            error();   // SFO function returns 2 if an error occurs & # of MEP
        }              // steps/coarse step exceeds maximum of 255.
    }



    //
    // Disable sync(Freeze clock to PWM as well)
    //
    SysCtl_disablePeripheral(SYSCTL_PERIPH_CLK_TBCLKSYNC);

    //
    // Initialize EPWM GPIOs and change XBAR inputs from using GPIO0
    //
    Board_init();

    //
    // Enable sync and clock to PWM
    //
    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_TBCLKSYNC);

    //
    // Enable Global Interrupt (INTM) and realtime interrupt (DBGM)
    //
    EINT;
    ERTM;

    EALLOW;
    HWREGH(myEPWM1_BASE + HRPWM_O_HRPCTL) |= 0x1;
    EDIS;

    periodFineCustom = 0.1f;
    count = 20.0f;

    compCount = (uint32_t)((count * 256.0f) + (float32_t)(periodFineCustom * 256.0f)); // Equal to 0x00001419
    HRPWM_setTimeBasePeriod(myEPWM1_BASE, compCount);
    HRPWM_setCounterCompareValue(myEPWM1_BASE, HRPWM_COUNTER_COMPARE_A, (compCount >> 1u)); // Equal to 0x000A0C00


    for(;;);
}

Thanks,

Simone

Hi Simone,

I will try the same by end of this week and let you know.
Thanks!

Hello,

sorry, do you have any news on this topic?

Thanks,

Simone

Hi Simone,

I haven't gotten chance to try this yet. I will try out this week and get back to you.

Thanks

Hi,

okok, thank you very much.

Simone

Hi Simone,
Apologies, I haven't tried your example

Meanwhile can you try downloading this lib - SFO_v8_fpu_lib_build_c28_driverlib_eabi.lib
Try running the example again with the updated lib for the SFO.

Thanks

Hi,

I just tried the new lib and it solved the problem. Is it included in the latest version of C2000 Ware? (For now we use 5.00.00.00 in our projects).

Thank you very very much for your help

Hi,

Okok, got it.

Thank you very much and have a nice day