• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 84 subscribers
  • Views 545 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:

TIDM-02002: Implementing blanking on TMS320F28377D

TIDM-02002: Fixed delay on comparator output

Lorenzo Lutti
Intellectual 665 points
Part Number: TIDM-02002
Other Parts Discussed in Thread: TMS320F28377D, TMS320F280049

Hello, I have a problem that probably is more difficult to describe than to solve.

I've ported the TIDM-02002 code to TMS320F28377D, as described in the previous referenced threads. Everything works as expected, except for the synchronous rectification.

Just to quickly summarize what the code does, the LLC tank current is fed to a comparator (CMPSS2) and then the comparator outputs are connected as follows:

* CTRIP2 goes to the Digital Compare submodule of EPWM3, which in turn goes to the Trip Zone submodule of EPWM3, which drives the PWM signals depending on the current. Basically it is used to "simulate" an ideal diode and to shut down the MOSFETs when the current changes direction.

* CTRIP2OUT goes to an output XBAR and then to a GPIO used as a debug/monitoring signal

Both signals are connected to the same source, COMPCTL.CTRIPSEL=COMPCTL.CTRIPOUTSEL=0. Normally they are set to 3 (the comparator trip signal is latched and it is reset by the PWM module at a certain point); for this test I have set it to 0 (asynchronous) for more clarity. However the problem is present with every mux setting.

The problem is that the trip output signal has a huge delay (about 2 microseconds) from the moment that the input current signal crosses the comparator threshold:

(Ignore the labels and the channel ranges)

The pink trace is the simulated current signal (the comparator trips when the signals goes low)
The light blue trace is the diagnostic signal connected to CTRIP2OUT
The blue trace is the EPWM3 output A (it shuts down immediately when the CTRIP2 trips, as expected)

From the falling edge of the pink trace and the rising edge of the light blue trace, there should be just the comparator propagation delay (that according to the datasheet it is 21 ns). Instead, there is a whole 2 microsecond delay. If I further reduce the duty cycle (below 2 microseconds), the CTRIP2OUT signal disappears completely. It is like there is some sort of "debouncer" that filters out impulses shorter than 2 microseconds.

It cannot be the digital filter of the CMPSS: the problem is also present on the asynchronous path (COMPCTL.CTRIPHSEL=0) which bypasses the filter, and anyway the filter is disabled (CTRIPHFILCTL and CTRIPHFILCLKCTL are both set to 0).

Since the original code running on TMS320F280049 evidently did not have this problem, I suppose that this is due to differences between the two MCUs, but at the moment I have no clue.

Any ideas? Thank you!

L.

  • 0
    TI__Intellectual 1880 points

    Hi Lorenzo,

    Our Subject Matter Expert is out of office. Please expect the response by next Wednesday. Thank you for your patience.

    Regards
    Srikanth

  • 0
    TI__Mastermind 42195 points

    L,

    as you pointed out the delay is too long, this is not typical. However I will point out that the typical delay from CMPSS detection to PWM output turn off is closer to 70nS its still much shorter than what you're seeing here.

    It does appear that the CMPSS type moved from type0 to type1 adding a few features. But fundamentally both devices use the same comparator at its core so times should be the same. https://www.ti.com/lit/spru566   

    I am going to ask that this gets reassigned to a CMPSS expert as they should best be able to address the issue.

    Regards,
    Cody 

  • 0 in reply to Cody Watkins
    Intellectual 665 points

    Thank you Cody. I have made a very stupid mistake: I was sure I had injected the signal directly on the CPU pins, instead I injected it before an amplifier/conditioning stage. This is most probably the source of the delay (see the simulated frequency sweep plot below).

    I will modify the circuit to confirm that this was the problem, and then if confirmed (very likely) I will update the real delay and close the issue.

    Sorry :-)

    L.

  • 0 in reply to Lorenzo Lutti
    TI__Mastermind 42195 points

    Not a problem, you preformed a very thorough analysis and provided the correct information which made it easy to determine that this was abnormal. I had also assumed that your stimulus was provided direct to the pin.

    Is it safe to assume then that the pink signal above was before the signal conditioning stage? Let me know if the issue has been confirmed and we can close the thread.

    Regards,
    Cody

  • +1 in reply to Cody Watkins
    Intellectual 665 points

    Hi Cody, it is confirmed. I have removed the filters (well, most of them) and now I got a much more sensible result:

    (Ignore the labels and the channel ranges)

    The pink trace is the simulated current signal (the comparator trips when the signals goes low)
    The yellow trace is the signal applied directly on the DSP pin (between the pink trace and this trace there is an opamp buffer which has a delay of its own)
    The light blue trace is the diagnostic signal connected to CTRIP2OUT
    The blue trace is the EPWM3 output A

    Now the delay is reduced to 245 ns, and half of if is still due to the delay introduced by the external buffer (the threshold is placed around the 50% of the step), so it is quite possible that the "true" delay is around 100 ns, which is not so far from the 70 ns that you conjectured.

    So yes, everything is fine! Thank you :-)

    L.