2
\$\begingroup\$

I found a mitigation for the problem that I couldn't post to e2e.ti.com because they demand a company email (University won't do). See my self-answer below.

I'm using a TI microcontroller TMS320F2837xD, with PWM1 as a synchronization master (sync pulse at TBCTR == 0) to PWM2 and PWM4 (and therefore to PWM5). I'm using up-down count and all PWM duty cycles are held constant at 50% with CMPA. I use the phase register of PWM 1 to 5 (PWMx.TBPHS) as a control variable, that I constantly change.

The problem: whenever I go from TBPHS > CMPA to TBPHS < CMPA, the PWM will miss the TBCTR==CMPA comparison and won't turn off the output. This is because at the synchronization event TBCTR is loaded with TBPHS, making it go from above CMPA to below CMBPA. Since the comparator doesn't care about TBCTR<=CMPA but only TBCTR==CMPA, the output set is missed. This behavior is described in Figure 1. Figure 2 shows the actual waveforms, and how the glitch affects the output voltage of the full-bridge I'm driving.

Is there a way to avoid this glitch?

Below I link some forum entries with the same problem. None of them really offered a solution:

Diagram of the cause of the missed compare.
Figure 1 - Diagram of the cause of the missed compare.

Glitch at ~14.45ms. The missed compare happens for D2 and D6, D3 and D7 are their complementary outputs, respectively. The voltage waveforms from two full-bridges, for which D0 - D7 are the gate signals.
Figure 2 - Glitch at ~14.45ms. The missed compare happens for D2 and D6, D3 and D7 are their complementary outputs, respectively. The voltage waveforms from two full-bridges, for which D0 - D7 are the gate signals.

\$\endgroup\$
4
  • 2
    \$\begingroup\$ just a remark on ti.com: get a .com (or other business-sounding top level domain) domain. That has worked perfectly well for me as a young student. Just put a simple "a website is about to be created here" page up and use the domain just for the email address. The cheapest trustworthy webhoster will do; I've got positive experiences with hetzner, though I only host my virtual machines with them \$\endgroup\$
    – Marcus Müller
    Commented Mar 31 at 12:44
  • 1
    \$\begingroup\$ e2e.ti.com are not against new users registering. I didn't see any part of the process that restricted me from registering and I don't use a company email address. \$\endgroup\$
    – Andy aka
    Commented Mar 31 at 13:59
  • \$\begingroup\$ @Andyaka - FYI there are documented examples of some people not being allowed to register on e2e.ti.com even though other people manage to do it e.g. here and here. So it seems that TI are against some new users registering - otherwise they would allow all email domains (perhaps they also check IP addresses etc). I have no idea what their actual rules are. \$\endgroup\$
    – SamGibson ♦
    Commented Mar 31 at 14:22
  • \$\begingroup\$ New posting requirements for E2E Support Forums was the notification from January 2021 when e2e.ti.com changed to require users to provide a company or select partner institution email address to be able to post on E2E. It wasn't clear which email domains are allowed / blocked, but I have an email address from a now defunct .co.uk ISP which wasn't blocked as still allows me to login. \$\endgroup\$
    – Chester Gillon
    Commented Mar 31 at 16:20

2 Answers 2

Reset to default
2
\$\begingroup\$

The mitigation I found was to use the action qualifier of CMPB to act as a "safeguard" against these missed compare events. I set CMPB to a value below CMPA, so when the comparison with CMPA is missed, there's still a second chance with CMPB. This is shown in Figure 1.

To do this, I program these registers like so:

#define PWM_MAX_DUTY_STEP        (0.02)      // maximum delta in every T_S_CONTROL

safety_net = PWM_MAX_DUTY_STEP/0.5 * period_reg;

// Set comparisons eventsc
EPwm2Regs.CMPA.bit.CMPA =  period_reg>>1;               // Duty always at 50%
EPwm2Regs.CMPB.bit.CMPB = (period_reg>>1) - safety_net; // Important to avoid glitches when duty crosses 50% downwards

// Action Qualify for channel A
EPwm2Regs.AQCTLA.bit.CAU = AQ_SET;                        // Action when TBCTR counts up past CMPA
EPwm2Regs.AQCTLA.bit.CAD = AQ_CLEAR;                      // Action when TBCTR counts down past CMPA
EPwm2Regs.AQCTLA.bit.PRD = AQ_SET;                        // Action of GPIO when reaches carrier max value
EPwm2Regs.AQCTLA.bit.ZRO = AQ_CLEAR;                      // Action of GPIO when reaches carrier zero
EPwm2Regs.AQCTLA.bit.CBU = AQ_CLEAR;                      // Action when TBCTR counts up past CMPB
EPwm2Regs.AQCTLA.bit.CBD = AQ_CLEAR;                      // Action when TBCTR counts down past CMPB

This is only a mitigation because, during the transition, one half cycle will become elongated to (CMPA + safety_net)/period_reg instead of just CMPA/period_reg.

This non-ideal behavior is shown in practice in Figures 3-5. In these scope screen captures, the voltages are the output of a full-bridge, using PWM1 and PWM2 with 50% duty and a phase-shift between them to create a 3-level PWM with zero vector. D2 and D6 are the offending PWM signals, with D3 and D7 being their respective, complementary outputs. Figure 3 shows the low cycle with the original TBPHS>CMPA, Figure 4 shows the elongated low cycle during the transition, and Figure 5 show the intended, shorter low cycle with TBPHS<CMPA.

Of course, if the change in TBPHS is greater than the safety_net, the glitch still happens (hence why I also use TBCTR=0 to clear the output), so a step limitation on TBPHS is needed. In my case this is OK since I have to employ a rate limiter anyway. If you choose a small safety_net value, you will have less elongation, but at the same time your step limit will be smaller and you will only be able to change TBPHS very slowly.

IMHO the true answer is that PWM the periphery should be corrected. This has been pointed out by TI personnel in the forum entries I link in the question. Honestly, this behavior is worthy of the errata sheet. It is non-obvious, and since it happens only on one event, it's extremely easy for it to go unnoticed and cause problems.

Mitigation of missed compare with CMPB acting as safeguard. Notice the elongated positive cycle on PWM2 when the transition occurs.
Figure 1 - Mitigation of missed compare with CMPB acting as safeguard. Notice the elongated positive cycle on PWM2 when the transition occurs.

Same instant as shown in the question, with the mitigation.
Figure 2 - Same instant as shown in the question, with the mitigation.

Original pulse with TBPHS > CMPA.
Figure 3 - Original pulse with TBPHS > CMPA.

Elongated pulse during transition.
Figure 4 - Elongated pulse during transition.

Pulse after the transition, with the new, correct phase shift.
Figure 5 - Pulse after the transition, with the new, correct phase shift.

\$\endgroup\$
0
1
\$\begingroup\$

The TI application report Leverage New Type ePWM Features for Multiple Phase Control mentions a similar issue and countermeasures in section 2.3.2 'Boundary Case.' You can refer to it.

enter image description here

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.