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.

TMS320F2800157-Q1: Avoid latching CMPSS-lite event before enabling CMPSS

Part Number: TMS320F2800157-Q1

Hi experts,

My customer is using the CMPSS for under-voltage protection of the OBC input voltage. 

They are using the CMPx_LP as input. Before starting, the system have 0 input and the voltage on CMPx_LP is around zero. The 12-bit DACL is also set as zero. However, the COMPL is still triggering. The COMPL is trippping even though the input and DAC are both zero, this would cuase below problems

As the system starts, the input voltage is 0. At this point, under-voltage protection is not enforced. This is achieved by disconnecting the COMPSTS from the ePWM trip signal. Nevertheless, the COMPSTS is still latched due to the above reason. 

As the the input voltage ramps up to some threshold, it would be the time to enbled the under-voltage protection. This is achieved by connecting the COMPSTS to the ePWM TRIP signal. However, as the COMPSTS is latched already, the ePWM would trip immdeiately when the COMPSTS is connected to ePWM. and the PWM is triped for one cycle, this would cause problems and customer does not want it.

To avoid ePWM tripping upon the enforcement of under voltage protection. Customer need to clear the COMPSTS before connecting it to ePWM. However, clearing the status would possibly losing a actual under voltage event. Therefore, customer wants to avoid clearing the COMPSTS beofre enabling the under voltage protection.

Is there any medthod to avoid eEPWM trip at the first cycle when enabling the undervoltage protection. WITHOUT CLEARING THE COMPSTS?

Also Is there any way to avoid COMPSTS latch until we wants it? 

image.png

  • Hi Hang,

    What you’re seeing is expected behavior when VIN = VDAC (both = 0V). Even if you haven’t routed CMPSS-Lite to the ePWM TRIP input, the CMPSS-Lite latch can still set internally due to normal comparator behavior around the switching threshold, so later when you connect it to ePWM you get that first-cycle trip. If you don’t want a stale latch to trip ePWM later, you have to prevent the latch from setting during the unarmed phase, or verify current status and clear only when safe.

    I would recommend not to latch during startup and keep the latch disabled, and only enable latching when you truly want UVP enforced. When you’re ready to enforce UVP, first read the real-time status (non-latched). If real-time status says UV is present, don’t arm and treat it as a real fault. If real-time status says UV is not present, then enable latch and connect to ePWM TRIP.

    Also, setting both the input and DAC to 0 can be a worst-case corner. If possible, set the UV threshold a few DAC counts away from 0 and/or add a bit more qualification in digital filter, so you don’t chatter right at the decision point.

    Best Regards,

    Masoud

  • Hi Masoud

    I would recommend not to latch during startup and keep the latch disabled

    How to keep the latch disabled? Which register should I use?

  • Hi Hang,

    Please check COMPCTL register. CTRIPOUTLSEL and CTRIPSEL can select: 0/1 = comparator output (async/sync), 2 = digital filter output (not latched) and 3 = latched output of the digital filter (this is the “latch” path). You should not select 3 until you’re ready to arm protection.

    Best Regards,

    Masoud

  • Got it,

    If we disabled it here, latch will still be triggered except it's not feed to the TZ. We are just not using the latch output instead of "disabling" it, right? 

    you have to prevent the latch from setting during the unarmed phase, or verify current status and clear only when safe.

    This solution would require "clear only when safe" as you said. This can work as one option.

    What about the "prevent the latch from setting" method you mentioned? 

    Regards,

    Hang

  • Hi Hang,

    Yes, selecting CTRIPOUTLSEL != 3 doesn’t disable the latch logic itself; it just means you are not using the latched path as the signal that gets routed onward.

    For the prevent the latch from setting approach, what I meant is that during startup route non-latched output. When you’re ready to arm UVP, read the real-time status and if UV is currently true, treat it as a real fault and don’t arm. If UV is false, then switch to the latched path and connect it to ePWM TZ.

    Best Regards,

    Masoud