TMS320F280039C: EPWM AQCTL with CMPA=0 boundary concerns

Hi Wayne,

I will need to consult with our other EPWM experts to confirm the answer to the customer's first two questions, but I believe the contention only occurs on the first CMPA=0 event that happens after AQCTL is updated, meaning the new action qualifier on the CMPA=0 event may take effect a period later than expected and your previous configuration for AQCTL would take effect instead. Using a non-zero value for CMPA would ensure that your new action qualifier takes effect on the first CMPA event after your action qualifier is updated. 

If this is the case(I will confirm this with our other experts as soon as possible), then there should not be any concerns with a CMPA=0 event as long as you are not updating AQCTL during runtime, assuming a late update to the action qualifier event does not affect your system during initialization.

I will need more time to answer the customer's third question as this adds another layer of complexity to the same scenario described in questions 1 and 2. I will get back to you before the end of the week.

Thank you,

Luke

Dear Luke,

So far, in the user's testing, if they avoided CMPA=0, there was no unexpected waveform (that is, the waveform was 100%, which was supposed to be 0%). However, in their application, they need 0% duty, so they are evaluating risks and concerns using 0% (CMPA=0) now.

When they used AQCTL in shadow with LOADMODE at ZERO, there was still unexpected waveform even though they did not update AQCTL during run time. This is why we are confused. But when they changed AQCTL LOADMODE to PRD (up-count), the unexpected waveform occurrence freq. became much lower, but there was still intermittent unexpected waveform.  

We are clarifying it and think this note seems one of the root causes.

Wayne

Hey Wayne,

Could you ask the customer to send their EPWM initialization code or any code where they write to the AQCTL or CMPA/CMPB registers during runtime? I am not sure there is a workaround in this case that involves using CMPA=0 for 0% duty, but perhaps we can find another configuration for achieving 0% duty cycle that won't introduce a contention as described in the note you shared earlier.

Thank you,

Luke

Dear Luke,

So far, I am trying to reproduce their problem in a simple way. Their issue is intermittent and not easy to reproduce. Therefore, we are not very sure if this note is realted.

During run time, they only set CMPB = 0 and don't change AQCTL.

Their initialization are:

up-count

AQCTL.CBU clear

AQCTL.ZRO set

CMPB shadow to active at ZRO.

I was miscommunicating. They use AQCTL as immediate mode and don't change it during run time.

But AQSFRC.RLDCSF is in shadow to active at ZERO by default and they tried to modify it to shadow to active at PRD in the initialization code by accident and found it seemed to lower the occurrence freq. of unexpected waveform.

However, the user is asking if we can firstly reply our questions in the first post because they want to clarify our notes in TRM no matter their problem is directly related to this note or not. They want to understand the risk and concerns when using CMPA=0.

For example, the symptom happens always or intermittently if the note conditions meet, and what is exactly the symptom?

Besides, even though AQCTL is in immediate mode by default, but AQSFRC.RLDCSF is in shadow by default. Does AQSFRC.RLDCSF in shadow matter?  or these two registers are independent when using CMPA/CMPB=0 and in shadow?

Wayne Huang

Hey Wayne,

The note in the TRM is describing a scenario where a TBCTR=CMPA=0 event occurs at the same time that the AQCTLA active register is being loaded from the shadow register. This behavior is not defined by the design team(meaning it is unknown what values will take effect in the active AQCTLA register during this event)which is why the TRM advises against using shadow loading of the AQCTLA register at the same time that an AQCTLA event occurs(same applies for AQCTLB). However, it is perfectly okay to have a CMPA or CMPB value of 0 as long as shadow loading is disabled, the CMPA and CMPB events will take priority over the TBCTR=0 event as described by Table 20-6. Action-Qualifier Event Priority for Up-Count Mode. My apologies if I made this unclear.

Have they disabled SHDWAQAMODE and SHDWAQBMODE during initialization? Even if they are not changing any values in AQCTLA or AQCTLB during runtime, the shadow registers may be getting repeatedly loaded into the active register during runtime and introducing contention events when CMPA or CMPB=0.

If SHDWAQAMODE and SHDWAQBMODE are disabled and they are still seeing this problem, that would be very unusual, I will try to determine whether we have seen this issue before while I await your response.

Thank you,

Luke

Dear Luke,

Based on your description,

case 1 is OK (this is the user's case, AQCTL in immediate (by default) and CMPA/CMPB in shadow loaded at ZRO. )

case 2 is not defined because PRD and ZRO still happens at TBCTR=0 cycle.

And  AQSFRC.RLDCSF in shadow by default has nothing to do with this note.

Is my understanding correct?

Hey Wayne,

I don't believe this note has anything to do with whether the customer is shadow or active loading the CMPA and CMPB values, it assumes these values are already 0 when TBCTR reaches 0. Are they using shadow loading for CMPA and CMPB, or just for AQCTL?

I have reached out to other experts on whether it is okay to use shadow loading for CMPA and CMPB in this scenario, I will get back to you as soon as possible.

Hey Wayne,

For F28003x, shadow loading should not be an issue in this scenario. I referred to Cody Watkins statement from this thread:

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/646249/tms320f28075-type-4-epwm-to-generate-full-range-0-100-duty-cycle-waveform-w-o-isr-intervention

"On newer devices like F2807x( anything Type 1,2,3,4) the shadow load occurs before CMPA is compared to TBCTR. This is closed with design and will always happen."

Case 1 is okay.

Case 2 is not defined since the TBCTR=CMPA=0 event occurs at the same time AQCTL is being loaded on TBCTR = 0.

AQSFRC.RLDCSF has nothing to do with this note and only relates to software force events. If changing this bit affects the frequency of the unexpected waveform, I suspect a software force event is causing this condition. Has the customer provided information on when they're using software force events in their system?

--Luke