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.

LAUNCHXL-F28379D: Is there a way to synchronise the CMPSS, DC and TZ modules to the PWM frequency?

Part Number: LAUNCHXL-F28379D
Other Parts Discussed in Thread: C2000WARE

Hello all. 

After advancing from my previous problem to get a GPIO to trigger a TZ1 one shot event, I’ve ran into a new one when configuring the CMPSS to do something similar. 

I have found that the comparator, even with some hysteresis added, seems to struggle substantially with what seems to be a noisy input. The comparator can generate multiple trips within a single switching period, causing unstable PWM output signals to be present. This is less than ideal for our application. 

It would be good if there was a way to synchronise the trip zones, comparator, digital compare or even all of these to the PWM signal frequency rather than to the time base clock which is substantially higher. This would ensure that a trip signal is only generated (or not) once within a single TBPRD.  Is something of the sort possible either directly or through software interrupt modifications? 

Also less than ideal is the fact that, when my GPIO goes high to enable PWM output, or a comparator is deasserted, the first switching period could have duty cycles that are substantially less than 50%. This causes substantial issues in our application which requires 50% duty cycle at all times. 

Is there similarly a way to deal with this problem? It would be very good if we could ensure something like the following:

Trip signal generated. Allow the current cycle to finish but stop all following PWM generation until comparator deasserted. 

If a trip signal is deasserted, do not allow a current cycle to start until the PWM switching period that was being generated at the instant the trip was deasserted was still asserted at the start of a switching period. 

Is there a way to have these two functionalities within the code? For a cycle by cycle trip, this may be more difficult, but we would probably look to “skip” X number or cycles following a cycle by cycle trip in a sort of “hiccup” mode. We could probably set this as a further OSHT mode with an interrupt that only clears the flag once N number of switching periods have been blanked. It would be important that the other points above regarding 50% duty cycle would be present in this functionality, too. 

I understand this may be a bit advanced for what the PWM generator is capable of in its basic configuration but some pointers would be appreciated to how it could otherwise be done in hardware. 

Best regards, 

JMH

  • At first glance it seems that using CMPSS_enableLatchResetOnPWMSYNCHigh(uint32_t base)

    and configuring the digital filter with output latch, quantification period and the likes to synchronise to the PWM. But I am using phase shift control so I am confused how I could do this for PWM2, although it could be easy for PWM1. 

    I would also be leaning towards simply using the microsecond delay function to stop the issue regarding PWM being allowed to pass when a trip is deasserted and vice versa - but I don’t think this is the most effective way to perform this. So any suggestions welcomed. 

  • Here’s a photo of what we want to avoid. Notice that the duty cycle of one of the channels is not 50% when the fault is cleared. We need that to be blanked and we need to make sure on the other hand that a cycle of EPWM1/2 is not blanked when a fault is initially set and is allowed to finish before a trip occurs at 50% duty. 

  • Does anyone have an input regarding the above issues? Having difficulty resolving it. 

    What if we utilised the latched output of the comparator and only set/cleared it at deterministic points in the PWM cycle? We would also need to make sure that the number of PWM1A/B cycles is equal, so that if A cycle is allowed to pass so is B, and if A is not allowed to pass, neither is A. The PWM has to be 50% at all times and cannot be less otherwise transformer saturation occurs. 

    TIA.

  • Hi JM,

    Sorry for the delayed response due to break, I am now looking into this.

    The comparator can generate multiple trips within a single switching period, causing unstable PWM output signals to be present.

    Have you looked at the digital compare event blanking window? This feature of the ePWM allows you to generate a blanking window within a PWM period to filter out noise by blanking events for a certain period of time. 

    Trip signal generated. Allow the current cycle to finish but stop all following PWM generation until comparator deasserted. 

    If a trip signal is deasserted, do not allow a current cycle to start until the PWM switching period that was being generated at the instant the trip was deasserted was still asserted at the start of a switching period. 

    It seems that the main issue here is once a trip event occurs, have the PWM finish their signals for the current PWM period, then ONLY on the next period trip the outputs. That way they are synchronized to the TBPRD instead of TBCLK. Is this correct understanding of your issue? Am I missing any detail?

    Best,

    Ma

  • Is there a blanking window on the F2837xD and the F2837xS? I thought this was brought into the subsystem in later Micros. 

    If there is a blanking window, how could one use this to ensure what I need? Would you set the blanking window equal to half the TBPRD, such that the TRIP signal is asserted some time during the OFF time of the PWM signal? How could you ensure the same action was applied to EPWMB? If the comparator TRIPs while EPWM1A is off, it may be asserted while EPWM1B is off, causing it to not be 50%.

    1. As per your second comment, That is exactly what I am looking for Ryan. The opposite of this behaviour should also be present on the reassertion of a trip, where a cycle is skipped before the PWM is fed to the gate driver such that a half cycle is not fed to the output. Basically, the PWM has to be 50% regardless of whether a trip is received. Instead of asserting or de asserting the PWM mid cycle, it should finish the current cycle then skip, or skip the current cycle and then resume depending on if the TRIP is asserted or deasserted. Hope that makes sense. 
  • Hi JM, 

    If you use a blanking window, it will prevent any signals from occurring from 0 to half your period. However if a trip occurs during this, the next period will not be affected which doesn't seem like that's the functionality you want based on my second question.

    I am thinking we will have to use the CLB in order to achieve the behavior you want. I am going to reach out to a CLB expert to come up with a proposed solution and will get back to you tomorrow EOD.

    Best,

    Ma

  • Hi JM,

    In order to achieve your required PWM signals, we will need to use the CLB module. Does the following diagrams capture all cases for your signal? IF so, the proposed solution would be using a finite state machine with the CLB. Would this be a feasible solution to implement? I hope the diagrams convey the overall flow. 

    clb_epwm_trip_sync_to_TBPRD.pptx

    Best,

    Ma

  • Hello Ma, 

    For the case where a PWM trip event occurs mid way through a switching period, this is absolutely perfect. 

    However, would this solution also work for the opposite case, where a PWM trip event is removed mid way through a switching period? This is what is actually happening in the photo in this thread a few replies above this one. My GPIO5 is set HIGH, removing the trip condition. Because the TRIP is removed mid way through the cycle, EPWM1B resumes switching with <50% duty cycle. The solution would also need to skip this cycle and only resume switching after that, assuming the TRIP has cleared. 

    I would test this myself but I am away from my desk now as it is a little late in the U.K. 

    Ill attempt to program the CLB tomorrow using the examples in the driverlib folder - is there any in particular that should be of interest to me to implement this? 

    thanks for your help. 
    JMH

  • 8228.clb_epwm_trip_sync_to_TBPRD.pptxHi JM,

    Yes this should also prevent the case where a PWM trip event is removed mid way through a switching period since the only way to resume normal PWM is at the end of the period in the slides I presented. 

    The driverlib folder is the best place to start with CLB examples. For the CLB input signals, it seems the main input signals that will be needed are the ePWM output signals, CMPSS TRIP signal, and the event when TBCTR == TBPRD. 

    Let us know if you need further help implementing CLB module. Here is also a video that could help with getting to know the CLB. 

    www.ti.com/.../6101205618001

    Sorry JM, here is an updated slide of what can occur of two scenarios... hope this makes sense. I added the S3 -> S2 logic which i forgot to add in previous solution.

    Best,

    Ma

  • Great solution Ma, I’ll give it a shot tomorrow. 

    I am transitioning I think to generating a single DCAEVT1/DCAEVT1 that used the Combinational OR of CMPSS2-CMPPS5 and the TZ1 from the GPIO5. I assume that the CLB block can instead use the DCAEVT1/DCBEVT1 as input to the logic block. 

    Just as a final question, will this logic need to be performed twice, one with DCAEVT1 as an input, and one with DCBEVT1 as an input such that these actions are applied to both the PWM1A/B? I suppose it is easy to apply the same logic to PWM2A/B, where I will just copy the exact same code and logic. 

    Just want to thank you again for your effort in this issue, TI always goes above and beyond to help customers with issues. 

    Best, 

    JMH.

  • edit: ahhh.. looks like there is no CLB block on the microprocessor that we can get in the 176 pin package… back to the drawing board… 

  • Hi JM, 

    That is really unfortunate, since the trip zone submodule is designed having to apply the action immediately on the outputs it does not seem possible to add this synchronization to the period without some other help from CLB or possibly ISR routine however ISR would apply CPU overhead.

    Just as a final question, will this logic need to be performed twice, one with DCAEVT1 as an input, and one with DCBEVT1 as an input such that these actions are applied to both the PWM1A/B? I suppose it is easy to apply the same logic to PWM2A/B, where I will just copy the exact same code and logic. 

    This is correct.

    If I may ask, what is the power topology or application you're trying to implement? Maybe there is an existing TI reference design that you can use as an example.

    Best,

    Ma

  • I’d be happy to use an ISR routine - that’s what I’m attempting to implement now.

    it is a phase shifted full bridge converter. I know there. Is a TIDM0200 package that implements current controlled PSFB which I am also looking at, but I do find it is quite difficult to get my head around. I’ll have another look at it tomorrow and see if it implements something similar, but I would assume it doesn’t and instead cuts off the duty cycle during a trip. In a normal PSFB during a trip it might be possible to just set the phase shift to zero to deliver no power to the load - however in our application the PWM must be removed entirely during a trip and cannot be reasserted until a new pulse command is received in the GPIO5. This is because it is for a capacitor charging power supply CCPS. So the required trip behaviour is slightly different. 

    Maybe there is a way to poll the status of the PWM GPIOs in an ISR and only clear or set the PWM trip signals (DCAEVT1 and DCBEVT2) when GPIO0 and GPIO1 are also zero, respectively. If you have any other suggestions on how to achieve this functionality with an ISR, please do let me know.

    best regards, 

    JMH

  • Hi JM,

    Maybe we can go back to the digital compare blanking window and how that could solve your issue. Applying a blanking window during the on time of your PWM signal should ensure that if any trip signals occur during this time it will not affect it the output. Only when the trip occurs outside the blanking window should your outputs be set to a certain state. This would indeed preserve the 50% duty cycle requirement.

    Would this work for your need?

    Best,

    Ma

  • That should certainly work. Can you possibly help me with how to achieve that? I think something with the digital filter latch could work too with some synchronisation to the PWM. I am happy with either solution that fits the bill, as long as we have the 50% duty requirement it doesn’t matter too much how we do it, but an easier solution is always better! Let me know your thoughts. 

    Kindest regards, 

    JMH

  • Hi JM,

    Most definitely can point you to our example for F2837xD that show cases how to configure a blanking window and is found within our C2000WARE SDK in C:\ti\c2000\C2000Ware_x_xx_xx_xx\driverlib\f2837xd\examples\cpu1\epwm\epwm_ex5_digital_compare_event_filter.c

    Please let me know if you have any further questions, I believe this solution would be the easiest to implement.

    Best,

    Ma

  • Hi Ma, 

    I have been looking at the blanking window today, and I’m still slightly confused by how to implement this to achieve what I would like. It is to my best understanding that the comparator blanking window will be well before the DC sub module, such that it cannot take effect on A/B individually. How could one ensure that if a trip was received in a given period, that the trip would not take effect until the next period? This would suggest that almost the entire period should be blanked. But I don’t think that would work. 

    If we use the latch of the comparator, I believe it could work, doing the following:

    TRIP goes HIGH mid way through the pulse. However, the latch should remain at zero. Then, the PWM clears the latch, at which point it becomes high, causing the PWM to trip. 

    Could you suggest how you would propose to set up the blanking window the achieve what I need? We only need one cycle following a trip and then no PWM until GPIO5 is high. 

    I suppose yet another problem is if we have more A pulses than B PWMs, or more B PWMs than APWMs. It would need to be that there is an equal number of pulses at all times. I have two counters (one for EPWMA ISR) and another for EPWMB ISR and I plan to use both of those to check if there has been an even number of pulses or not before activating the trip. Maybe this would be simple just by utilising PWMB ISR, since no trips activate until the falling edge of PWMB. Basically everything needs to be completely symmetrical. So I was looking to maybe even force DCAEVT1/DCBEVT1 trips rather than using the CMPSS. The difficulty would be the very small time period from when B goes low to when A goes high, which would be equal to the dead time of the PWM.

    Thinking about it, is it guaranteed that when the PWM module begins switching, that EPWMA is always high first?  

  • Hi JM,

    The blanking window will remove any DCAEVT1/2 or DCBEVT1/2 events from occurring within the period defined. You can use the DCEVTFILT for both A/B.

    Could you instead generate an interrupt that will trigger on a trip event, set a global flag variable letting you know a trip event occurred. Then generate an event trigger on CMPC when TBPRD - 5, to check if this flag had been set and then use the trip zone module to set the outputs to a certain state for the next period. Then you can configure your Trip Zone to be CBC clear so the outputs resume to original state after the tripped period. You can also set the global variable back to the untrip state. 

    Thinking about it, is it guaranteed that when the PWM module begins switching, that EPWMA is always high first?  

    Depending on your configuration and where TBCTR is when resuming operation will determine when the EPWM signal will go high.

    Best,

    Ryan Ma

  • Hi Ma.

    Hmm, sounds like a good solution, although as mentioned when the trip occurs there can be no more switching (after one complete cycle has finished) until the GPIO again goes high. If we used CBC clear the outputs May reset. Here is a similar idea:

    Disable Trip Zone Signals for EPWM1/EPWMB in the initialisation sequence. Set CMPD at some point following the falling edge of PWMA and before the falling edge of PWMB. 

    We can then use CMPD to generate a PWM ISR. With the global flag variable being set by the GPIO5 to show a trip event has occurred. Then, in the PWM ISRs, immediately check it a trip flag has been set. If a trip flag has been set, and the ISR spots it when it is launched after CMPD occurs in the AQ, and enables the PWM trip zone signals. 
    we can most likely tailor CMPD value so that allowing time for latency. 
    This way, if timed correctly, EPWMB should have just finished switching by the time the TRIP has propagated to the PWM module - disabling both EPWMA and EPWMB in the next cycle. The trip flag can then be reset at the ENABLE pulse in the rising edge GPIO trigger ISR. Does this seem like a workable solution? How predictable and constant is the latency across devices? Is there anything that can affect latency at runntime where a solution like this may not be workable for a safety critical system intended for production? 

    just a note, you mentioned TBPRD-5, that seems like a small number - how much latency in nanoseconds could one expect in this device including launching of an ISR, and propagation of the fault to actually tripping the PWM? In this case the return from the interrupt latency is not a matter, since the PWM should have tripped anyway well before this. I intend to time the CMPD such that the actual trip of the PWM occurs exactly at CTR=ZRO or just a very small number of counts following PWMB going low, such that our 100-150ns of dead-time can account for any unexpected changes in latency. Let me know your thoughts. 

  • Hi JM,

    We can then use CMPD to generate a PWM ISR. With the global flag variable being set by the GPIO5 to show a trip event has occurred. Then, in the PWM ISRs, immediately check it a trip flag has been set. If a trip flag has been set, and the ISR spots it when it is launched after CMPD occurs in the AQ, and enables the PWM trip zone signals.

    Are you planning to use the AQ submodule or Trip zone to update the outputs within that same ISR? If you're talking about trip affecting the output latency it's is only about 2-3 CC which has been spec'ed within our datasheet. This also sounds like a workable solution, there should be enough time between falling edge of ePWMA and the next period for CMPD ISR generation to check if a trip has occurred or not and set the outputs.

    how much latency in nanoseconds could one expect in this device including launching of an ISR, and propagation of the fault to actually tripping the PWM?

    Including the launch of ISR is something dependent on the application code and could be tested by having a gpio toggle within the ISR to view the latency within your system.

    Best,

    Ma