• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 6 answers
  • Subscribers 85 subscribers
  • Views 2565 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.

TMS320F280049: How to trigger DCAEVT1.sync while the DCAEVT always be triggered

Benjamin Zhou
Expert 4000 points

Part Number: TMS320F280049

Hi Team,

   My customer now is using CMPSS to trigger DCAEVT1, and then to generate the DCAEVT1.sync for PWM synchronization, while the CMPSS always triggered DCAEVT1(the CMPSS input always higher than the setting value), the DCAEVT1 should always in triggered states, but the DCAEVT1.sync only triggered once during the test.

Support Need:

How to configure the DCAEVT1.sync to triggered every PWM period while the DCAEVT always be triggered(the CMPSS input always higher than the setting value) ?

Expect for your reply, thanks.

 

Best Regards

Benjamin

  • 0
    TI__Guru 54925 points
    Hello,

    If you want a sync every PWM period you could configure the sync to come from another EPWM through the EPWMxSYNCI signal which will be ORed with the DCAEVT1.sync (see the block diagrams of the sync signals in the TRM). Will that work or am I misunderstanding the goal?

    Whitney
  • 0 in reply to Whitney Dewey
    Intellectual 280 points

    Hi, Whitney

    I found a problem that the DCAEVT.sync didn't synchronize with DCAEVT.force when triggered the DCAEVT issue. And DCAEVT.sync always delay DCAEVT.force 4 cycles.
    Could you give a reasonable explanation about this?

    Was the delayed time constant?

    And did this delayed time differed from chip( ig. 28032 or 280049)?


    Thanks

  • 0 in reply to Whitney Dewey
    Intellectual 280 points
    Hi, Whitney

    I found a problem that the DCAEVT.sync didn't synchronize with DCAEVT.force when triggered the DCAEVT issue. And DCAEVT.sync always delay DCAEVT.force 4 cycles.
    Could you give a reasonable explanation about this?

    Was the delayed time constant?

    And did this delayed time differed from chip( ig. 28032 or 280049)?


    Thanks
  • 0 in reply to Born Ming
    TI__Expert 4000 points
    Hi Dewey,
    The customer want to use the CMPSS to generate DCAEVT1.sync which used for unique feature of PWM control, it can't to generate by other sync source, could you kindly double check for the DCAEVT1.sync? and the constant delay is critical for the unique feature of PWM control, could you kindly confirm the delay timing?
    Expect for your reply, thanks.

    Best Regards
    Benjamin
  • 0 in reply to Benjamin Zhou
    TI__Mastermind 24095 points
    Hi Benjamin,

    Please refer to Figure 18-50. DCAEVT1 Event Triggering
    There will be a delay of 2 TBCLK cycles (i,e. PWM Clock) between DCAEVT1.sync and DCAEVT1.force.
    If you do not want any delay, you can choose synchronized version for DCAEVT1.force as well by setting DCACTL[EVT1FRCSYNCSEL] bit.
  • 0 in reply to Subrahmanya
    Intellectual 280 points
    Hi Subrahmanya,

    Is the delay of 2 TBCLK cycles fixed between DCAEVT1.sync and DCAEVT1.force? With our test result, there have 4~5 cycles delay. And the delay result is also same as we using 28032. Can you give a reasonable explanation about this?
    Besides, as the 15.3.9.4.1 chapter of sprui33.pdf describle:

    NOTE: The TZn signals, when used as a DCEVT tripping functions, are treated as a normal input
    signal and can be defined to be active high or active low inputs. ePWM outputs are
    asynchronously tripped when either the TZn, DCAEVTx.force, or DCBEVTx.force signals are
    active. For the condition to remain latched, a minimum of 3*TBCLK sync pulse width is
    required. If pulse width is < 3*TBCLK sync pulse width, the trip condition may or may not get
    latched by CBC or OST latches.

    Does the delayed time relate with the above NOTE?

    Expect for your reply, thanks!
  • 0 in reply to Born Ming
    TI__Mastermind 24095 points
    Did you mean sprui33a.pdf? Yes- there is a difference between DCAEVT1.sync and DCAEVT1.force signals.
    In sprui33a.pdf you can refer to the Figure 18-50. DCAEVT1 Event Triggering diagram.
    The difference is due to the Sync indicated in the diagram.
    This is same on 2803x as well.
    If you want DCAEVT1.sync and DCAEVT1.force to be same you need to choose the Sync signal for DCAEVT1.force as well.
    As mentioned above, please use DCACTL[EVT1FRCSYNCSEL] for that configuration.
  • 0 in reply to Subrahmanya
    Intellectual 280 points
    Hi Subrahmanya,

    At first, thanks for your suggest, there has no delay time between DCAEVT1.sync and DCAEVT1.force signals when I set DCACTL[EVT1FRCSYNCSEL] bit to sync.

    Besides, does there have other ways to remove the delay time? As we do not want to change DCACTL[EVT1FRCSYNCSEL] bit to sync, because of control strategy.
    With our test result, there have 4~5 cycles delay when do not choose the Sync signal for DCAEVT1.force. What I want to confirm was that if the delay of 4~5 cycles was fixed.

    Expect for your reply, thanks!
  • 0 in reply to Born Ming
    TI__Mastermind 24095 points

    Hi,

    Thanks for confirming that you do not observe delay with DCACTL[EVT1FRCSYNCSEL] bit set.
    I understand that you would not want to change the configuration for control reasons.
    The trip event is asynchronous to the PWM time base clock and is generated by analog comparator.
    That's why there is a need for synchronizer to be able to latch that signal into the PWM clock.
    Synchronizer will inherently have little variability up to 2 PWM clock cycles - depending on when the DCEVTx is asserted w.r.t. the PWM clock.
    That's the only variation you should expect and is inherent to the nature of synchronizing asynchronous signals.

  • 0 in reply to Subrahmanya
    Intellectual 280 points
    Hi,
    I'm sorry. I still confused about your reply. You said "Synchronizer will inherently have little variability up to 2 PWM clock cycles ", but why did we found that it taked more than 2 PWM clock cycles between DCAEVT1.force and CAEVT1.sync?

    Please help, thanks!
  • 0 in reply to Born Ming
    TI__Mastermind 24095 points
    Hi,
    How are you measuring the delay?
  • 0 in reply to Subrahmanya
    Intellectual 280 points
    Hi,
    I configured the DCAEVT1.force and DCAEVT1.sync to be related with PWM1. DCAEVT1.sync signal be used to synchronize the PWM1 TB count(TBCTR) to zero. And DCAEVT1.force signal be used to force PWM1A low(set asynchronous by DCACTL[EVT1FRCSYNCSEL]), while PWM1B be configured to be forced high when the TB count up to 10 LSB(by AQC and CMP). Then I measured the time between PWM1A falls low and PWM1B rises high. There had 4~5 cycles delay time.
    Is my measuring manner correct?

    Thanks!
  • 0 in reply to Born Ming
    TI__Mastermind 24095 points
    Hi,

    You could measure this way - but note that there will be additional delay of DCAEVT1.sync to clearing on the TB count and Action Qualifier action taking effect. That's why you are seeing 2 additional cycles of delay. So, what exactly is your concern? If you are using DCAEVT1,force to trip the PWM output and DCAEVT1.sync to synchronize the time base counter and Set/Clear PWM based on Counter values - this delay can not be avoided.
  • 0 in reply to Subrahmanya
    Intellectual 280 points
    Hi,

    What our concern is consistency.
    For example, did this inevitable delay time change because of chip batch or operational temperature drift?
    In other words, when I used another chip to test the delay time, did the test result change to 9~10 cycles?

    Expect for your reply, thanks!
  • 0 in reply to Born Ming
    TI__Mastermind 24095 points

    Hi,

    No. Variation is only due to the Synchronizer up to 2 cycles as I mentioned earlier and that too is because of the asynchronous comparator event being synchronized to the PWM clock domain. Beyond that the delay is predictable and doesn't vary from device to device or operating conditions.