TMS320F280049C: HRPWM period and duty cycle control

Hi Gökhan,

You can control duty cycle and period using High-Resolution edge placement. Note that to do both, you should enable MEP control of both edges and set shadow loading for SMPAHR to be on "CTR = 0 and period" with autoconversion enabled. This is because the HRPWM module has internal calculations that load (internally) on CTR = PRD so that it can finely place the first edge and second edge.

You can do so by using CTLMODE set to 0 (edge placement is controlled by CMPAHR/TBPRDHR) and EDGMODE set to 11 (both edges are controlled with high-resolution) within the HRCNFG register.

In terms of the scale factor, there some are example calculations within the TRM. Did you already take a look at the following?

• 8.15.1.5.2 Scaling Considerations for CMPAHR
• 18.15.1.5.4 High-Resolution Period for TBPRDHR

Also, if there are typos, please do point them out to me and we can take a look and fix if necessary  

What are the conditions that you are trying to change your PWM duty cycle for? Always mention that diagram can be helpful here if you feel inclined to sketch out something. 

Best regards,

Allison

Hi Gokhan,

Can you help me to understand at what conditions you will need to change the duty? LLC is typically a variable frequency topology hence in our reference designs, we want close to 50% duty cycle and for both PWM legs to match duty. Reference designs like TIDA-10062, PMP41081, PMP23340, etc.

Are you saying that you wish to control both duty and frequency at the same time. This would be very complex to control. Or do you mean there will be instances where you will shift from constant duty, variable frequency to variable duty, constant frequency?

If the latter is the case, we have done something similar in our TIDM-02013 reference design where we explicitly shift between frequency mode and phase shift mode based on the control effort dictated by the compensator. You can reference this and implement something similar to switch between frequency mode and duty mode

Regards,

Peter

Hi Allison,

Thank you for your reply. 
I have already checked the related subsection in TRM about HRPWM.

The condition is, after frequency is up to a limit. Then I will start with decreasing duty cycle to have more gain.

Best regards,

Gökhan

Hi Peter,

Thank you for your reply.

Like your latter case, I will start duty cycle control after the frequency becomes my upper limit. 

I will check TIDM-02013 SW

Best Regards,

Gökhan.

Hello Again Peter,

The problem with TIDA-10062 or PMP is they don't use HRPWM as I could see.

When i try to configure the AQ settings as they it produces symmetrical PWMs for xA and xB (push pull PWM with 50% duty cycle), the sysconfig provides warning:

" If in up & down count mode, and doing both edge control then in this case you need to have action qualifier settings as follows: CMPxU = set, CMPXD = clear, no actions on TBCTR= PRD or ZRO"

I still go with my settings the PWM frequency is not stable and it varies around 1kHz.

Then, when I change the AQ settings as sysconfig want I could generate stable hi-res PWM frequency but those settings are not suitable for LLC PWM driving.
I want these kind of PWMs:

I could generate this with regular PWM ( not Hi-res). But when i tried it with Hi-res. it does not work. I think it is related to the that warning ı wrote above

Hi Peter,

In TIDM-02013, they use below AQ settings:

// CTR = CMPA@0 , xA set to 1
//
EPWM_setActionQualifierAction(base1, EPWM_AQ_OUTPUT_A , EPWM_AQ_OUTPUT_HIGH, EPWM_AQ_OUTPUT_ON_TIMEBASE_ZERO );

I suppose this should mean when timebase counter is zero make xA set, isn't it?

But when I select the same thing with sysconfig the the tool provides warning that you explained above.

The generated code for my selection is:

Hi Gokhan

For a lot of the HRPWM driverlib functions, these are actually aliased to the respective EPWM driverlib function unless they are specifically editing the a high-resolution configuration, such as the DBREDHR register or the CMPAHR register. So HRPWM_setActionQualifierAction and EPWM_setActionQualifierAction in this case perform the same action. 

Referring to the design guide it mentions that the primary leg PWMs are configured in up-down count mode and is centered on the period. This is the same configuration that is described in the SysConfig warning, so the PWMs in TIDM-02013 conform to our HRPWM AQ requirements.

Which section of the code are you referring to? You may be looking at the SR legs on the secondary side

Regards,

Peter

Hi Peter,
Thank you for your support again.

I want to share the latest status about my problem here.

Like we discussed yesterday, I still can not have control over CMPAHR register. 

Whatever I do, it does not change anything. 
I found an example "hrpwm_ex4_duty_updown_sfo". In there CMPAHR has effect and I have mainly same settings for PWMA output with this example. 

Also, the Active high complementary deadband settings works fine for symmetrical PWMB generation but there is 2 PWMclock (2 * 10ns ) differences between PWMA and PWMB. As you know from yesterday, we have figured out that with changing FED value but we still don't know why it happens.

Best Regards,

Gökhan Bayraktar

My run time code for updating the TBPRD, TBPRDHR,CMPA and CMPHR is as follow:

EPwm1Regs.TBPRD=coarse_prd;
EPwm1Regs.TBPRDHR=periodFine*256;

CMPA_1=(coarse_prd/2) + cmpA_var;

EPwm1Regs.CMPA.bit.CMPA=CMPA_1;

EPwm1Regs.CMPA.bit.CMPAHR=CMPA_HR_1;
// HRPWM_setCounterCompareValue(myEPWM0_BASE, HRPWM_COUNTER_COMPARE_A, compCount); (with thisfunction still no effect of CMPAHR)

EPwm1Regs.DBRED.bit.DBRED=RED_1;
EPwm1Regs.DBFED.bit.DBFED=FED_1;

Lastly,

When I change CMPAHR in sysconfig I can see changes in PWM output.

But I can not change anything in runtime. It is so interesting!

Last of last,
There is this interesting behavior.

With initial sysconfig settings and after I set coarse_prd=50 and periodFine=0; 
There is 20ns pulse width difference between PWMA and PWMB.

Then, I change periodFine variable to any number under 255. The PWM frequency changes. Then, I make it 0 as in the beginning.
Now the 20ns difference disappears. Why, I do not have any idea.

Also, When I set CMPAHR and CMPBHR different from sysconfig ( changing these in runtime still has no effect). Then, if I change the periodFine any number from zero, there is jitter at the PWMB output. The frequency of PWMB is not stable.

Hi Gokhan,

I suspect the issue with your run time code lies in the below line

EPwm1Regs.CMPA.bit.CMPAHR=CMPA_HR_1;

Recall that the CMPAHR is a 16-bit register but the bottom 8 bits are ignored in the hardware. So you should only care to write to the upper 8-bits. If you are writing a value from 0 to 255, then you will only ever be writing to the bottom 8-bits which will not affect the hardware.

It should instead be

EPwm1Regs.CMPA.bit.CMPAHR = CMPA_HR_1 << 8;

See below excerpt from the TRM

Regards,

Peter

Hello Peter,

I have written multiple of 256 to that register since the beginning. 

In the run time code I multiply the TBPRDHR with 256 therefore I write values  between 0-255 to the TBPRDHR.

Here is the register values

Hi Gokhan,

Your register view shows the correct values so I'm not sure why you are able to adjust the CMPAHR with the SysConfig but not with bitfield or register writes. Would you be willing to share your project or a subset of your project with us so that we can more easily debug the HRPWM output? I don't notice anything wrong with your run-time code but there may be a HRPWM configuration that's missing which we haven't seen

Regards,

Peter

Hi Peter,
I believe I have sent you some mail about the issue and last update. Have you received them?

Hi Gokhan,

There seems to be some confusion then. I had thought that you had wanted to continue the debug through E2E. I will follow up with your email. Thanks

Regards,

Peter