TMS320F280049C-Q1: Jitter is generated when using HRPWM + deadband module in UpCount mode

Hi OH,

Do you mind linking the original thread if possible? Want to be sure I have all the context before I can provide a proper response.

Best Regards,

Allison

Hi Allison,

Thank you for your reply.

Please refer to the thread below.

TMS320F280049C-Q1: How to remove jitters in HRPWM

Best regards,
O.H

Hi OH,

Thanks for the reference. Another question - I noticed you are referencing a F2837xD device example - are you using this device? Or can you confirm you are implementing this on F280049C?

What other PWM/HRPWM configurations are you setting? Can you share the full PWM initialization so I can make some suggestions?

In general, could you describe the type of signal output you are trying to create? A diagram/quick sketch of the output is always helpful if you feel the need.

Best Regards,

Allison

Hi Allison,

Thank you for your reply.

Allison Nguyen said:

Thanks for the reference. Another question - I noticed you are referencing a F2837xD device example - are you using this device? Or can you confirm you are implementing this on F280049C?

Sorry... This time, f28375d.

Allison Nguyen said:

What other PWM/HRPWM configurations are you setting? Can you share the full PWM initialization so I can make some suggestions?

In general, could you describe the type of signal output you are trying to create? A diagram/quick sketch of the output is always helpful if you feel the need.

I'm confirming with the customer now.

Best regards,
O.H

Hi OH,

Okay - good to know it is F28375D device, thanks for clarifying. And feel free to update when the customer responds to confirm.

Thanks!

Allison

Hi Allison,

Allison Nguyen said:

What other PWM/HRPWM configurations are you setting? Can you share the full PWM initialization so I can make some suggestions?

Please check this attachment.

    EPwm8Regs.TBCTL.bit.PRDLD = TB_SHADOW;  // Set Immediate load

     //
     // PWM frequency = 1 / PeriodConfig
     //
    EPwm8Regs.TBPRD = 360;//PeriodConfig = 360

     //
     // Set duty 50% initially and initialize HRPWM extension
     //
    EPwm8Regs.CMPA.bit.CMPA = 180; //PeriodConfig / 2;
     EPwm8Regs.CMPA.bit.CMPAHR = (1 << 8);
     EPwm8Regs.CMPB.bit.CMPB = 180; //PeriodConfig / 2;
     EPwm8Regs.CMPB.bit.CMPBHR = (1 << 8);
     EPwm8Regs.TBPHS.all = 0;
     EPwm8Regs.TBCTR = 0;

     EPwm8Regs.TBCTL.bit.CTRMODE = TB_COUNT_UPDOWN;
     EPwm8Regs.TBCTL.bit.PHSEN = TB_DISABLE;   // ePWM1 is the Master
     EPwm8Regs.TBCTL.bit.SYNCOSEL = TB_SYNC_IN;
     EPwm8Regs.TBCTL.bit.HSPCLKDIV = TB_DIV1;
     EPwm8Regs.TBCTL.bit.CLKDIV = TB_DIV1;

     //
     // LOAD CMPA on CTR = 0
     //
     EPwm8Regs.CMPCTL.bit.LOADAMODE = CC_CTR_ZERO_PRD;
     EPwm8Regs.CMPCTL.bit.LOADBMODE = CC_CTR_ZERO_PRD;
     EPwm8Regs.CMPCTL.bit.SHDWAMODE = CC_SHADOW;
     EPwm8Regs.CMPCTL.bit.SHDWBMODE = CC_SHADOW;

     EPwm8Regs.AQCTLA.bit.CAU = AQ_SET;
     EPwm8Regs.AQCTLA.bit.CAD = AQ_CLEAR;

     EALLOW;

     EPwm8Regs.HRCNFG.all = 0x1353;

     //
     // Turn on high-resolution period control
     //
     EPwm8Regs.HRPCTL.bit.HRPE = 1;

     //
     // Synchronize high resolution phase to start HR period
     //
     EPwm8Regs.TBCTL.bit.SWFSYNC = 1;


     EPwm8Regs.TBCTL.bit.PHSDIR = 1;        // Count up after SYNC event
     EPwm8Regs.TBPHS.bit.TBPHS = 180;

     EPwm8Regs.GLDCFG.bit.CMPA_CMPAHR = 1;
     EPwm8Regs.GLDCFG.bit.CMPB_CMPBHR = 1;

     //
     // Load on CTR = ZERO_PRD (2) / ZERO (1)
     //
     EPwm8Regs.GLDCTL.bit.GLDMODE = 2;

     //
     // One shot mode and global load enabled
     //
     EPwm8Regs.GLDCTL.bit.OSHTMODE = 1;
     EPwm8Regs.GLDCTL.bit.GLD = 1;

     //
     // Write to PWM1 GLDCTL2 will result in simultaneous write to PWM2 GLDCTL2
     //
     EPwm8Regs.EPWMXLINK.bit.GLDCTL2LINK = 0;//PWM1 - 1;  PWM1=1
     EPwm8Regs.DBCTL.bit.OUT_MODE = DB_FULL_ENABLE;
     EPwm8Regs.DBCTL.bit.POLSEL = DB_ACTV_HIC;
     EPwm8Regs.DBCTL.bit.IN_MODE = DBA_ALL;
     EPwm8Regs.DBCTL.bit.SHDWDBREDMODE = 1;
     EPwm8Regs.DBCTL.bit.SHDWDBFEDMODE = 1;
     EPwm8Regs.DBCTL.bit.LOADREDMODE = 0;    // Load on Counter == 0
     EPwm8Regs.DBCTL.bit.LOADFEDMODE = 0;    // Load on Counter == 0
     EPwm8Regs.DBCTL.bit.HALFCYCLE = 1;
     EPwm8Regs.DBRED.bit.DBRED = 4;
     EPwm8Regs.DBREDHR.bit.DBREDHR = 0x0;
     EPwm8Regs.DBFED.bit.DBFED = 4;
     EPwm8Regs.DBFEDHR.bit.DBFEDHR = 0x0;

     EPwm8Regs.HRCNFG2.bit.EDGMODEDB = HR_BEP;    // DBREDHR and DBFEDHR
     EPwm8Regs.HRCNFG2.bit.CTLMODEDBRED = 0; // Load on ZRO
     EPwm8Regs.HRCNFG2.bit.CTLMODEDBFED = 0; // Load on ZRO
     EPwm8Regs.DBREDHR.bit.DBREDHR = (0 << 9);

     EDIS;

Allison Nguyen said:

In general, could you describe the type of signal output you are trying to create? A diagram/quick sketch of the output is always helpful if you feel the need.

Please check the diagram below.

The customer performed various verifications based on the sample source code "hrpwm_deadband_sfo_v8.c".
As a result, setting TBPRDHR to a non-zero value during initialization will cause jitter.

[Question]
Q3:Will jitter occur if I use a dead band module and set the high resolution frequency (TBPRDHR)?

[Verification]
Do not change the contents from the sample source code (use the contents of the HRPWM2_Config function as is)
Partial change (*ePWM[PWM2]) to EPwm8Regs. For details on the settings, please refer to the "verification 1 register settings.txt" in the attached file.

[Verification.1-1]
After initialization, do not change the values of TBPRD, TBPRDHR, CMPA, and CMPB.
Result: No jitter occurred from PWM8A,B.

[Verification.1-2]
After initialization settings, set fixed values to TBPRD, TBPRDHR, CMPA, and CMPB of PWM8 in CLA.
The fixed values set are as follows.(TMR's "15.14.1.5.3 Duty Cycle Range Limitation" is within TBPRD-3>CMPA, CMPB>3.)
Result: Jitter occurs from PWM8A,B. The frequency of occurrence is once every 0.5 seconds.

Best regards,
O.H

Hi OH,

Thanks for all the information! Diagram was super clear and very helpful.

One clarification - are you using up-count? Or up-down count? This thread originally discussed issues with up-count mode and jitter, and the diagram shows up-count, but it looks like up-down count is being used in the configurations. This does play a role in what is compatible with HRPWM settings, so I'd like to clarify before I make other suggestions. 

Does occur every time you are updating CMPxHR or TBPRDHR values? Or does it seem unrelated?

Best Regards,

Allison

Hi Allison,

Thank you for your reply.

Allison Nguyen said:

One clarification - are you using up-count? Or up-down count? This thread originally discussed issues with up-count mode and jitter, and the diagram shows up-count, but it looks like up-down count is being used in the configurations. This does play a role in what is compatible with HRPWM settings, so I'd like to clarify before I make other suggestions. 

The customer ultimately wants to use it with UP-Count.
UP-DOWN is used only when verifying sample code.

Allison Nguyen said:

Does occur every time you are updating CMPxHR or TBPRDHR values? Or does it seem unrelated?

Customers used UP-Count to additionally validate the following patterns:

• After register initialization, update TBPRD, TBPRDHR, CMPA, CMPB with fixed values in CLA → Jitter occurs
• When initializing registers, update TBPRD, TBPRDHR, CMPA, CMPB with fixed values  → Jitter occurs
• After register initialization, update TBPRD, TBPRDHR, CMPA, CMPB with fixed values in CLA. However, change to TBPRDHR=0 → No problem
• When initializing registers, update TBPRD, TBPRDHR, CMPA, CMPB with fixed values. However, change to TBPRDHR=0 → No problem

Best regards,
O.H

Hi OH,

If the customer is trying to control both edges (rising and falling) of the PWM with high-resolution (MEP control of both edges), they unfortunately cannot use up-count. They must use up-down count for this. This is due to internal calculations needed for HR capability on each edge and loading of values on the CTR = 0 and CTR = PRD events. The best way to implement HRPWM for period and duty control is to use up-down count with action qualifiers on CMPx-up and CMPx-down. 

Is there a specific reason the customer wants to use up-count?

Best Regards,

Allison

Hi Allison,

Customer comments are listed below.

Allison Nguyen said:

Is there a specific reason the customer wants to use up-count?

My ultimate goal is to use Up Count.
I would like to avoid changing the previous operation, such as changing the PWM pulse operation or interrupt timing.

When using UpCount without using a dead band, we have confirmed that jitter does not occur even if the CMPxHR/TBPRDHR values are updated.

When I tested it by adding a dead band, no jitter occurs even if the CMPxHR value is updated.
When the TBPRDHR value is entered, jitter has appeared. (If I enter a value other than 0 as the initial value, jitter will occur)
Also, jitter will occur if a dead band setting is used during up-down.

I understand that using up-down counts should be considered as an option. However, I would like to understand the cause of the jitter that occurs without depending on up-down/up-count.

Best regards,
O.H

Hi Allison,

After further investigation by the customer, they found that SFO was also involved.
Please let me ask you a few additional questions.

Q4:When jitter occurs, calling the SFO function returns 2 (ERROR), could you please tell me the possible reason why 2 is returned?
We understand that TRM returns 2 when "MEP_ScaleFactor" is greater than 255, but we don't understand how it relates to this case.

Q5: What happens if the SFO function is executed only once at startup, and the SFO function is not called after that?
For example, it would be helpful if you could provide us with information on what kind of problem might occur if the SFO function is not called for nearly an hour.

[Conditions for jitter]
The SFO function is called at regular intervals.

[Conditions for no jitter]
The SFO function only be called during initialization, and not be called after that.
Jitter does not occur even if the CMPxHR and TBPRDHR values are updated in Up-count mode.

Best regards,
O.H

Hi O.H,

Allison is currently out of office. Please expect her response to be delayed by a day or two. I apologize for any inconvenience.

Best Regards,

Delaney

Hi Delaney,

Thank you for your follow. I understood. We look forward to answer.

BTW, the customer has the results of their investigation and have some additional questions. Listed below.
==================

We found that when jitter occurs in SFO operation, the MEP_ScaleFactor value and the Epwm1Regs.HRMSTEP register value fluctuate.
Jitter occurs when the return value of SFO() changes from abnormal(2) to normal(1).
If the TBPRDHR register is set to 0, jitter does not occur.

[Initialization process]
SFO() is executed in the While() statement until completion(SFO_INCOMPLETE). At this time, nothing is done even if an error occurs.
The MEP_ScaleFactor = 63 and the Epwm1Regs.HRMSTEP = 63.

[Normal SFO execution]
When SFO() is executed after initialization, the status(return value) alternates between abnormal(2) and running(0).
The MEP_ScaleFactor = 32767 and the Epwm1Regs.HRMSTEP =63.

Occasionally status(return value) would be normal(1), and the MEP_ScaleFactor = 0, and the Epwm1Regs.HRMSTEP = 0.

If SFO() is run again after normal (1) is returned, it would again alternate between abnormal (2) and running (0).
At this time the MEP_ScaleFactor = 32767, and the Epwm1Regs.HRMSTEP = 0.
The values ​​do not change even if it returns to normal after that.

Q6:What is the definition of PWM operation when the MEP_ScaleFactor value and HRMSTEP register value are 0?

Best regards,
O.H

Hi OH,

Thanks so much for the patience. It will take some time for me to review your last 3 responses, but I wanted to ask if you have tried developing using the Sysconfig GUI? If not, this may be helpful to prevent you from trying to implement configurations that are known to be incompatible. For example, there are notes about shadow loading etc.

Specifically, I wanted to highlight a few of the guidelines for High Resolution Period. When using TBPRDHR:

• Auto-conversion must always be enabled
  • Auto-conversion mode performs the calculation for CMPxHR, DBREDHR etc.
• TBPRD must have shadow loading enabled
• Shadow loading of CMPA/BHR should occur when TBCTR=0 or PRD
  • New values from the user are loaded to the shadow registers only at CTR=ZERO, but the shadow mode of for the registers must be set to both ZERO AND PERIOD. The CTR=PRD event is used for specific internal logic inside the HRPWM module.
• MEP should control both edges
  • Note that edge control of both edges is not supported with up-count mode. Instead, up-down count mode must be used
• You should have action qualifier settings on CMPxU and CMPxD (no actions on TBCTR= PRD or ZRO)
  • This is due to the shadow loading scheme that utilizes the ZERO and PRD events to load values

These notes can be found in the TRM/SysConfig, but we are also taking some actions in the future to document these in an easier manner

Best Regards,

Allison

Hi Allison,

Thank you for your supports.

Inform the customer about whether or not Sysconfig is being used and the avobe precautions.

It's okay if there is no information in response to a question. For example, details about SFO().

Best regards,
O.H

Hi OH,

Ok sounds good, let me know if there are further questions and I can reach out to an SFO library expert if needed.

Best Regards,

Allison

Hi Allison,

O.H said:

It's okay if there is no information in response to a question. For example, details about SFO().

I'm sorry. There was a misunderstanding in the above sentence.
What I meant was that “no more information than is currently available to the public” is acceptable as a response.

Allison Nguyen said:

I can reach out to an SFO library expert if needed.

It would be much appreciated if you could have the above checked by an expert.
And I look forward to your answers to Q1-6.

Best regards,
O.H

Hi OH,

Ah I see what you mean, sorry for misunderstanding. Yes, please allow a few days for me to reach out on your questions and what information I can relay. I will update on any findings later this week.

Best Regards,

Allison

Hi Allison,

Thank you for your supports. And sorry for rush you. Is there any update? It would be helpful if you could tell me the situation.

Best regards,
O.H

Hi OH, 

Yes, apologies for the late response. I reached out and the SFO experts; we already know some cases that are documented in notes of the TRM and in SysConfig where jitter can occur with certain configurations, and they are in discussion with design now on why the jitter does occur (we are awaiting response). I am still reviewing the information of all 6 of the above questions and verification tests provided and will leave a response for all of them tomorrow. Thanks again for the patience!

Best Regards,

Allison

Hi Allison,

Thank you for your reply.

I understood. We will pass on the information you provide to the customer. We will contact you again if any additional questions arise.

Best regards,
O.H

Sounds good, O.H. I'll close this thread for now. Feel free to respond back here or open a new thread if needed.

Best Regards,

Allison

Hi Allison. OK!! Thank you for your kind supports!!

Best regards,
O.H

Hi Allison,

Allison Nguyen said:

[1] When using the deadband module, the sample source code and E2E recommend up-down counting of PWM operation. Is it related to the range shown in Figure 15-88 of TMR's "15.14.1.5.3 Duty Cycle Range Limitation"?

[2] Is there no problem even in Up count mode as long as it is within the range of Duty Cycle Range Limitation (CMPA, CMPB values are within the range of 4 to TBPRD-4)?

In regard to the first two questions, I want to reiterate that you cannot use up-count if you are trying to apply high-resolution control to both edges of the EPWM. If you are using HR in both-edge mode (MEP control of both edges), you must use up-down count. This is because the CTR=0 and CTR=PRD events are used by internal HR logic to load the HR delay values for each edge independently.

They operated it under the conditions you provided, but the 10ns jitter was not eliminated.

We received the following additional question from a customer. Could you please answer it?

Allison Nguyen said:

The SFO function is used to calibrate the width of the MEP steps based upon ambient conditions such as temperature. This is why it is typically called at regular intervals so that the calibration can occur regularly. If you do not call it, the MEP step size will not change in response to ambient conditions. As per the device documentation, this routine returns a 1 when calibration is finished and a new scale factor has been calculated, or a 0 if calibration is still running. The routine returns a 2 if there is an error, and the MEP_ScaleFactor is greater than the maximum 255 fine steps per coarse EPWMCLK cycle. In this case, the HRMSTEP register will maintain the last MEP scale factor value less than 256 for auto conversion.

Q7: For example, consider the case where the HRSTEP value is 63 when the SFO function is called at startup and changes to 61 over time.
Is it correct to assume that the frequency behavior at that time will be as follows?

[Conditions]
・Up count mode, AutoConversion enabled
・TBCLK: 10ns
・Set 130kHz (TBPRD: 769, TBPRDHR: 15123)

Step 1. When HRSTEP is 63. When SFO is not called even if it changes to 61 over time.
MEP Steps value is 15:
When HRMSTEP is 63: 129.998kHz (Calibration successful)
When HRMSTEP changes from 63 to 61: 129.997kHz (Calibration failed)
→If calibration is not performed, a difference of 1Hz will occur.

Step 2. When SFO is called again and the HRSTEP value is set to 61.
When MEP Steps value is 14:
When HRSTEP is 61: 130.000kHz (calibration successful)

The above calculation process is referenced from "15.14.1.5.4 High-Resolution Period", "Step 2: Fractional value conversion for TBPRDHR register", "The auto-conversion then automatically performs the calculation, such that TBPRDHR MEP delay is scaled by hardware to:" in the TRM.

Allison Nguyen said:

[6] What is the definition of PWM operation when the MEP_ScaleFactor value and HRMSTEP register value are 0?

The MEP Scale Factor (and HRMSTEP) indicate how many MEP steps are equivalent to one coarse step, so if they are 0 (assuming autoconversion is enabled) there likely would not not be any HR delay applied to the signal since there is no measurement of MEP steps in relation to coarse step.

Q8: When you say that the "HR delay is not applied, does it mean that even if we put a value in the HRMSTEP register, it will be the same as when the register value is 0?

Q9: Also, could you please tell me the conditions under which the HRMSTEP value will be 0, and if there is a possibility that the result of calling the SFO function will be 0, what are those conditions?

Best regards,
O.H

Hi OH,

Thanks for the response. Please let me reach back out to the SFO experts on these inquiries.

Best Regards,

Allison

Hi Allison,

Sorry for rush you.

Is there any update?? It would be helpful if you could let me know the situation.

Best regards,
O.H

Hi Allison,

Sorry for rush you.

It's fine to reply via private chat, so I would appreciate it if you could reply.

Best regards,
O.H