Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

HRPWM MEP step size clarification

Hello,

I have a customer who is using the HRPWM on a TMS320F2806x device.  The device is currently running at 60MHz with an expected MEP step size of 150psec.  This concern arises when the MEPstep size is varied from 1 to 111.  This modification produces a change in frequency of only 8nsec instead of 16.67ns.  Is this the correct behavior of the module?  If so, can someone clarify.   Customer question below.

Thanks

 

I have been playing around a great deal with the HRPWM verifying the behavior of the TBPRDHR and TBPRD registers.

From the SFO() routine, I am getting the MEP_ScaleFactor variable is 111.  Using a 60MHz processor, this tells us that the MEP step size is about 150psec as expected.

 Now, if I carefully measure the PWM period using precision frequency measurements using the following register setup:

 

EPwm4Regs.TBPRD = 300;                          // Set timer period, PWM frequency = 1 / period in hardware

EPwm4Regs.TBPRDHR = MEPStepSize<<8;             // update the MEP register for the fine period adjust

EPwm4Regs.CMPA.half.CMPA = 150;

EPwm4Regs.CMPB = 150;

 

(NOTE:  I did change to setup registers per the manual.  Can you confirm that I am doing this correctly?

 

            device->HRCNFG.bit.EDGMODE = HR_BEP;

            device->HRPCTL.bit.HRPE = 1;                    // Enables HR PERIOD control

)

 

I should get a base frequency of 200KHz with a duty cycle of 50% which I do.

 

Now I adjust MEPStepSize from 1 to 111.  If I do this, I get a change in period of only about 8 nsec.  I can see this reliably as I sweep through MEPStepSize from 1 to 111.

 

I would expect this value to be 16.67nsec +/- measurement accuracy.

 

As an experiment, I adjusted the MEPStepSize sweep to 1 to 222, doubling the number to see what would happen.

 

It indeed doubled the change in period up to about 15nsec.

 

This leads me to believe that the TBPRDHR register uses all 8 bits for the MEP – but this kind of contradicts the manual which states that this number should be in MEPSteps.  If TBPRDHR was in MEPSteps, then one would think that the sweep from 1 to 111 would go through the whole 16.67nsec coarse step but one can see that sweep from 1 to 222 yields close to 16.67nsec – suggesting that perhaps the TBPRDHR register really scales 0 to 255 down to the 1 to 111 (in this case) MEP step size…

Can you please verify this for me?  (See my HR register setup below…)

 

IT IS INCREDIBLY IMPRESSIVE TO BE ADJUSTING PERIODS WITH 150psec RESOLUTION!!! 

            EALLOW;

            device->HRCNFG.all = 0;

            device->HRCNFG.bit.AUTOCONV = 1;

            device->HRCNFG.bit.EDGMODE = HR_BEP;

            device->HRPCTL.bit.HRPE = 1;                    // Enables HR PERIOD control

            device->HRCNFG.bit.CTLMODE = HR_CMP;

            device->HRCNFG.bit.HRLOAD  = HR_CTR_ZERO;

            device->AQCTLA.bit.ZRO = AQ_SET;                // Set PWMxA on Zero event

            device->AQCTLA.bit.CAU = AQ_CLEAR;              // Clear PWMxA on Up-Count CompareA event

            EDIS;

             EALLOW;

            device->HRCNFG.all = 0;

            device->HRCNFG.bit.AUTOCONV = 1;

            device->HRCNFG.bit.EDGMODE = HR_BEP;

            device->HRPCTL.bit.HRPE = 1;                    // Enables HR PERIOD control

            device->HRCNFG.bit.CTLMODE = HR_CMP;

            device->HRCNFG.bit.HRLOAD  = HR_CTR_ZERO;

            device->AQCTLA.bit.ZRO = AQ_SET;                // Set PWMxA on Zero event

            device->AQCTLA.bit.CAU = AQ_CLEAR;              // Clear PWMxA on Up-Count CompareA event

            EDIS;

  • Devin:

    There is one setting in the customer's code which is incorrect:

    HRCNFG.bit.HRLOAD  = HR_CTR_ZERO; should instead be:

    HRCNFG.bit.HRLOAD  = HR_CTR_ZERO_PRD;

    With the first setting, high-resolution would only apply to one edge and not both edges for high-resolution period control.