• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 2806 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

HRPWM for for hi-res duty and period control in up-down count (symmetric) mode

TMS320F280049: HRPWM for for hi-res duty and period control in up-down count (symmetric) mode

Mike Twieg
Intellectual 960 points
Part Number: TMS320F280049


After trying and failing to configure the ePWM and HPWM to implement center aligned, symmetric high resolution duty cycle control, I found this post, which seems to work. However I cannot understand why it works. In fact, based on how I choose to interpret the documentation and various other related posts, this actually shouldn't be possible.

Here's my current thought process:

1. To get symmetric output, the leading and trailing edges have to be shifted by equal amounts, but in opposite direction. For example if I want to decrease the pulse width by half of a TBCLK period, I would have to delay the leading edge by 0.25 TBCLK (~64 MEP ticks) and advance (negative delay) the trailing edge by 0.25 TBCLK (~64 MEP ticks).

2. The delay on the leading edge is straightforward, but the HRPWM can't actually advance an edge (causality and all that). Instead, the trailing edge is advanced by having the course ePWM output shifted one whole TBCLK period earlier, and adding a delay of 0.75 TBCLK with the HRPWM (~192 MEP ticks).

3. Each ePWM output has only one delay associated with it (CMPAHR for ePWMxA, CMPBHR for ePWMxB). Therefore it shouldn't be possible to generate the differing HR leading and falling edge delays required.

Obviously I'm wrong, but I can't tell where. Are there actually multiple HR delays for each output channel? Or perhaps the CMPAHR value is actually inverted when counting down? Either way, what in the linked example code sets up such sophisticated behavior?

  • 0
    Intellectual 960 points

    Okay now I see in SPRU556M, it lists the F28004x devices as having a type 4 HRPWM. SPRU556M suggests looking in the general TRM for details, but the TRM only mentions type 2 HRPWM. The only info I can find on type 4 is table 38 in SPRU556M, which mentions it "Added one-shot shadow-to-active reload." Looking in the TRM, I see this mentioned in the ePWM section (18.1), not sure what it has to do with HRPWM...

    Since there doesn't seem to be a reference guide for the type 4 HRPWM, which of the existing reference guides is most useful for users of the 2807x/2837x/28004x devices?

    Also in my original post, those MEP tick numbers are assuming HRMSTEP=255 (not realistic, but makes the math a bit simpler).

  • 0 in reply to Mike Twieg
    TI__Guru 52040 points

    I just received this thread. I will get back to you in a minute.

  • 0 in reply to Nima Eskandari
    TI__Guru 52040 points
    Mike,

    There are a lot of questions, so lets go at it one at a time.
    First, the F28004x has ePWM type 4. The TRM for this device actually describes the type 4 ePWM.
    So take a look at www.ti.com/.../sprui33a.pdf

    No allow me write up some explanations for your other questions above.
  • 0 in reply to Nima Eskandari
    Intellectual 960 points

    Hi Nima, looking forward to hearing your explanations.

    This thread has quickly overlapped with another I started... that is, both were quickly derailed into comparing documents and semantics, while not really addressing the fundamental issues.

  • 0 in reply to Mike Twieg
    TI__Guru 52040 points

    Yes as far as the documentation goes, both descriptions you find in the TRM for this device are for EPWM/HRPWM type 4. There was a mistake mentioning type 2 for HRPWM.

  • 0 in reply to Nima Eskandari
    TI__Guru 52040 points

    First thing I want to reiterate one thing below, which seems like you already know,
    CMPAHR: Is for delaying CHA edges (falling edge, rising edge, or both) and HAS NOTHING TO DO WITH CMPA
    CMPBHR: Is for delaying CHB edges (falling edge, rising edge, or both) and HAS NOTHING TO DO WITH CMPB

    So with this said, you can move edges of the PWM with high resolution to a different position by delaying them.

    You can move one edge, or both edges. 

    You are absolutely right when you say you can't move the edge backwards (make it happen at an earlier time using HRPWM only). You need to redo calculation to know what the new PWM values need to be, then use HRPWM to delay the edges (or edge) to get the exact PWM signal you want (Duty and Period). 

    No you cannot have different delay values for falling and rising edge delays using only CMPxHR. You can however use DBREDHR and DBFEDHR to do specific thing to RED and FED but that is not what we are currently discussing.

    But still having HRPWM delay on both or one edge, with ePWM deciding the number of course steps, should allow you to get the desired signals you need.

  • 0 in reply to Nima Eskandari
    Intellectual 960 points
    Hi Nima, thanks for the response.
    I follow what you're saying so far; one can't use CMPxHR to produce different delays on rising/falling edges. But the example code in the original thread accomplish delaying the falling edge and advancing the rising edge by only using CMPAHR. I know that using the DB modules, or dynamically updated CMPxHR after each edge, would allow for more capability, but I was curious how this example accomplishes it without such methods. I assume it's limited to symmetric delay/advance, but this isn't mentioned in documentation, as far as I can tell.
  • 0 in reply to Mike Twieg
    TI__Guru 52040 points

    Okay Mike. I can describe the code in the example you mentioned.

    Here are the key HRPWM register configuirations.

    (*ePWM[j]).TBCTL.bit.CTRMODE = TB_COUNT_UPDOWN;

    This is necessary when using Period control. "ePWMx may only be configured for up-count or up-down count modes. High-resolution period is not compatible with down-count mode"

    (*ePWM[j]).HRCNFG.bit.EDGMODE = HR_BEP;

    (*ePWM[j]).HRCNFG.bit.CTLMODE = HR_CMP;

    This means both edges are affected by the CMPAHR. This way you can use both period and duty cycle in high resolution mode.

    (*ePWM[j]).HRPCTL.bit.HRPE = 1;

    Enable the high resolution period.

    This way you can have a high resolution period and high resolution duty cycle. based on  what CMPA and CMPAHR values you choose you can get the desired ePWM signal.

    What is the confusion? Maybe I'm not understanding the question. In my head right now I can create any PWM output with HR duty and HR period. I just have to do the calculations for CMPA, CMPAHR, and PERIOD and PERIOD HR. I can place the edges in any position with the right values.

    Nima

  • 0 in reply to Nima Eskandari
    Intellectual 960 points

    My question isn't really related to period control, just to duty control in updown count mode. I'll try and clarify the question again.

    First, we have two assumptions:

    1. As you point out above, in this example the high resolution positioning of both edges is determined only by CMPAHR.

    2. It's also been pointed out that CMPxHR can only delay edges, regardless of the direction of the counter.

    Therefore it stands to reason that in this example, that in increase in CMPAHR should cause the rising and falling edges to be delayed equally, which would shift the pulse from center alignment and not change duty cycle. This is what I was observing with the code that I initially wrote.

    But somehow, in the example code, an increase in CMPAHR causes rising edges to be delayed and falling edges to be advanced equally. This creates the desired HR duty cycle modulation without losing center alignment. So are the assumptions wrong, and if so what is actually happening in the module to produce this behavior?

  • 0 in reply to Mike Twieg
    Expert 2595 points

    Hello Mike,

    I struggled with this issue a few months ago and there is a lack of clarity from the TI documents on this topic.

    Please see this conversation where I formulated a hypothesis regarding the mechanisms inside the module and TI confirmed that it was "more or less the same way as you have described".

    Regards,

    Pierre

  • 0 in reply to Pierre Bouchet1
    Intellectual 960 points

    HA, that's a very clever way of exposing what's going on internally (CMPA being changed by one TBCLK and CMPHR being complemented). The only remaining issue is specifically what configuration settings enable this behavior. But based on what I've seen so far, TI is not interested in helping.

    Thanks Pierre!

  • 0 in reply to Pierre Bouchet1
    Intellectual 960 points
    HA, that's a very clever way of exposing what's going on internally (CMPA being changed by one TBCLK and CMPHR being complemented). The only remaining issue is specifically what configuration settings enable this behavior. But based on what I've seen so far, TI is not interested in helping.

    Thanks, Pierre!
  • 0 in reply to Mike Twieg
    Expert 2595 points

    Hello,

    I spent quite some time before understanding this. The key idea is that symmetric duty-control configuration needs to be treated as a special case of the period control configuration, except you never actually change the period, only the duty cycle.

    So you just perform the procedure in the chapter High-Resolution Period Configuration then you can leave TBPRDHR as is and start using CMPAHR. 

    The pitfall here is that the procedure cannot work unless you perform the synchronization exactly as they describe it, including enabling TBCLKSYNC beforehand. What is not said explicitely is that this one is a special synchronization which seems to be necessary for the HRPWM to initialize properly.

    Hope it helps,

    Pierre