TMS320F280049C: EPWMxA and EPWMxB may appear to output pulses referencing different CMPA

Hi O.H.

What is GLDCTL[GLDMODE] configured to? Are you using a software trigger to trigger the global load?

Thank you,

Luke

Hi Luke,

Thank you for your reply.

Luke Jones said:

What is GLDCTL[GLDMODE] configured to?

GLDCTL[GLDMODE] = 0(Load on Counter = 0 (CNT_ZRO)).

Others are as follows.
GLDCTL  = XXX0 0000 0X10 0001
GLDCFG = XXXX X000 0111 1011

Luke Jones said:

Are you using a software trigger to trigger the global load?

yes. The "EPWM_setGlobalLoadOneShotLatch function" is executed in the fixed cycle control interrupt.

Best regards,
O.H

Hi O.H,

Based on the information you have provided, I don't see how it is possible for different CMPA values to take effect for the outputA and outputB action qualifer events. Is it possible there is some trip event associated with output A that would clear it earlier than expected?

Thank you,

Luke

Hi Luke,

Luke Jones said:

Is it possible there is some trip event associated with output A that would clear it earlier than expected?

In particular, no events related to clearing ePWMxA were found.

The customer has done some research and it appears to be related to the deadband.

When "Execute GlobalLoadOneShotLatch" and "PWM counter = 0" match, which behavior of ①, ②, and ③ will occur in the specifications of the F280049C?
In the actual observed waveform, it seems that the event of ③ below is occurring.

The setting of the dead band sub-module is the red circle in the figure below.

TRM "18.7.2 Dead-band Submodule Additional Operating Modes - Global Load Support - Note" has the following description, and I thought it would be ②, but it is different from the actual behavior.

”When DBRED/DBFED active is loaded with a new shadow value while DB counters are counting, the new DBRED/DBFED value only affects the NEXT PWMx edge and not the current edge.”

Best regards,
O.H

Hi O.H

Can you provide a scope shot of when the issue occurs? Can you also list all of the settings that are being updated by the global load before the cycle where the issue occurs?

Thank you,

Luke

Hi Luke,

Luke Jones said:

Can you provide a scope shot of when the issue occurs?

Please refer to the diagram below

Luke Jones said:

Can you also list all of the settings that are being updated by the global load before the cycle where the issue occurs?

They set breakpoints before and after executing global load to check.
Changes were seen in the ePWM registers only in the following registers, and no changes were seen in other ePWM registers.
・DBRED, DBFED (changes between 100d and 200d)
・TBCTR (counter value changes each time)
Please let me know if there are any additional registers that we should pay particular attention.

[additional information]
In the program that the customer is running, instead of resetting the PWM counter to 0 when it reaches CTR = PRD, it receives an external signal and rewrites the counter value to the TBPHS value(= 0) resetting.
The procedure is below.
(1) Preset 0 as a fixed value in the TBPHS register
(2) Set TBCTL[PHSEN]=1 so that an external signal can be input to the “Load” of the counter through DCAEVT1.sync.
(3) If an external signal arrives while the PWM counter is counting up, the counter value is rewritten to the TBPHS value(=0) at that point and reset to 0.

I will share it for a slightly special 0 reset method.

Best regards,
O.H

Hi O.H.

I believe this statement may be the cause of the issue:

”When DBRED/DBFED active is loaded with a new shadow value while DB counters are counting, the new DBRED/DBFED value only affects the NEXT PWMx edge and not the current edge.”

Perhaps the first edge delay is getting loaded while the DB counters are already counting, so the updated edge delay does not take effect until the next cycle. The edge delay on output B however starts later, so it uses the latest edge delay value.

Could you try loading DBRED and DBFED on period instead? Perhaps the 1 cycle timing advantage will ensure that both DBRED and DBFED will be loaded with the latest value before the dead-band counters begin counting.

Thank you,

Luke

Hi Luke,

Thank you for your reply.

Luke Jones said:

”When DBRED/DBFED active is loaded with a new shadow value while DB counters are counting, the new DBRED/DBFED value only affects the NEXT PWMx edge and not the current edge.”

We may have misunderstood the "PMWx edge" in the description above.
Is it correct that my understand with the diagram below?

If yes, I understand your explanation of the effectiveness of predictions and countermeasures.

Luke Jones said:

Perhaps the first edge delay is getting loaded while the DB counters are already counting, so the updated edge delay does not take effect until the next cycle. The edge delay on output B however starts later, so it uses the latest edge delay value.

Could you try loading DBRED and DBFED on period instead? Perhaps the 1 cycle timing advantage will ensure that both DBRED and DBFED will be loaded with the latest value before the dead-band counters begin counting.

Best regards,
O.H

Hi O.H.

The "current edge" in the figure on the right is correct, however the "next edge" would not occur until one period later. "Current" and "next" in this case must refer to the same edge, either the current rising edge and next rising edge delay, or current falling edge and next falling edge delay.

Let me know if shadow loading DBRED and DBFED on period instead of zero resolves this issue.

Thank you,

Luke

Hi Luke,

Thank you for your support.

Luke Jones said:

Let me know if shadow loading DBRED and DBFED on period instead of zero resolves this issue.

In the customer's usage, it cannot be adopted because it does not reach the PRD.

[Additional investigation]
As another countermeasure, they tried the method of "rewriting the counter value to PRD with an external signal" and the problem no longer occurred.(see following diagram).
If we don't do "RESET with counter = PRD", we guess that the timing when the dead band runs is slightly different and the global load didn't go well.

[additional questions]
Q1:Is there any problem in using the above "rewriting the counter value to PRD with an external signal"? Please let me know if you have any concerns.
Q2:Is there a recommended example or sample code for "rewriting the counter value to 0 with an external signal (resetting the counter)"?
It seems that there is no sample program, so I am using the phase shift sample program to put zero in TBPHS.

Best regards,
O.H

Hi O.H.

Q1: Very glad to hear that resetting to PRD instead of zero resolves the issue. To clarify, you are doing this by loading TBPHS with PRD, and using EXTSYNCIN to induce a sync event?

Q2: The phase shift example is most likely the closest example to your configuration.

Perhaps you may have addressed this already, but my only concern with your configuration is whether the EXYSYNCIN pulse will arrive as a syncin signal at a consistent timing, or is there some risk that it will come in late and TBCTR will reach 0 on it's own before the sync pulse? I would suggest using a very large EPWM period to avoid this and having some trip zone protection if the sync pulse does not arrive on time.

Thank you,

Luke

Hi Luke,

Thank you for your reply.

Luke Jones said:

Q1: Very glad to hear that resetting to PRD instead of zero resolves the issue. To clarify, you are doing this by loading TBPHS with PRD, and using EXTSYNCIN to induce a sync event?

Q2: The phase shift example is most likely the closest example to your configuration.

A1:They put the PRD value in TBPHS and trigger a sync event with EXTSYNCIN.
A2:I have informed the customer of the information received.

Sorry for the additional question.
Based on the results of the additional investigation, could you please provide your views and explanations about the cause of this problem?
We would like to clarify the cause to avoid similar problems in the future.

Best regards,
O.H

Hey O.H

I believe this is an undocumented bug in the dead-band module, however this seems very similar to a known issue with the Action Qualifier module. We have documented this bug in the F28003x TRM, it will be included in the F28004x TRM later this year. Refer to the Configuration Requirements for Common Waveforms section in the F28003x TRM.

I will reach out to the design team to determine the root cause of this issue.

Thank you,

Luke

Hi O.H

Would you be able to provide a .out file or example code that demonstrates this issue? I will provide this to the design team so that they can simulate it and confirm when the issue occurs.

Thank you,

Luke

Hi Luke,

Sorry for late reply...
Thank you for your support.

Luke Jones said:

I believe this is an undocumented bug in the dead-band module, however this seems very similar to a known issue with the Action Qualifier module. We have documented this bug in the F28003x TRM, it will be included in the F28004x TRM later this year. Refer to the Configuration Requirements for Common Waveforms section in the F28003x TRM.

I will reach out to the design team to determine the root cause of this issue.

The above has been shared with the customer and has been understood. 

Luke Jones said:

Would you be able to provide a .out file or example code that demonstrates this issue? I will provide this to the design team so that they can simulate it and confirm when the issue occurs.

At the customer's request, let me share the software in a private chat. so please accept my requested friendship.

Best regards,
O.H

Hi O.H, I've accepted your request.