Hi there,
I am currently working on a PLECS model and try to generate code to run on a C2000 DSP (TMS320F28379, 2xCPU). In PLECS model we use Powerstage Protection block to stop PWM outputs during overcurrent. The Signal output was connected to a digital output port, which is used to control a LED on hardware board.
During hardware testing, we observed a significant delay—about 40 ms—between the moment the PWM stops and the corresponding change in the protection signal output:
Blue: digital output pin LED1, remains at ~2V throughout the scope range. Status jump of LED1 was not visible on the scope. Yellow: voltage over transistor being controlled by PWM
As stated in help document, there is only delay of 100ms while activating the Powerstage Protection, not by turing off PWM.
The Powerstage Protection block has a dedicated enable GPIO specified in the component mask. Set the “Powerstage enable signal” to “Digital output” and configure the polarity and GPIO number. This GPIO is directly linked to the PWM peripheral status.
When you take the Powerstage Protection block’s signal output and connect it to another Digital Output you are inserting a delay of one sample period. In your case the sample period is 40 usec (1/25e3) so the delay you are observing matches. The Powerstage Protection block’s signal output can be useful for other things such as resetting integrators in your control loop.
Hi Bryan,
thanks for your reply.
Acctually the observed delay was 40 milli seconds, exactly 1000x of the CPU sample period. Such a lang period has made me confused.
And if I use the dedicated DIO pin, in which type the pin be then configured? Push pull or open drain?
BR
Z.W.
Acctually the observed delay was 40 milli seconds, exactly 1000x of the CPU sample period. Such a lang period has made me confused.
My apologies for misreading that. Interesting - do you have a model or minimal example you could share? Are you stopping the PWM by changing the “En” input to the powerstage block or are you activating the fault with a Trip Signal input?
And if I use the dedicated DIO pin, in which type the pin be then configured? Push pull or open drain?
Hello Bryan,
Thank you very much for your support and for taking the time to look into my issue.
do you have a model or minimal example you could share?
I would really like to share the model with you for better understanding, but unfortunately, the model is part of an internal company project and I’m not allowed to share it externally due to confidentiality policies. I hope you understand.
Are you stopping the PWM by changing the “En” input to the powerstage block or are you activating the fault with a Trip Signal input?
The stop of PWM should be triggered by Analog Trip Signal. There are no digital trip signal enabled. The signal Error_Reset comes from CAN-Bus, which share the same CPU as we are talking about and has a sample time of 1ms.
I’d be happy to provide more details—such as screenshots, block settings, or a simplified version of the setup—if that would help. Please let me know what would be most useful for your analysis.
Apologies for the delay here, I can take this over for Bryan
I’ve tried to replicate this on my end but I’ve been unable to do so, so I have a few questions to help clarify if you don’t mind!
What frequency are you running your PWM(s) at?
When you say CPU sample period are you referring to the discretization step size set in the scheduling tab of the Coder options? This is set to 0.00004 or 4e-5?
Have you tried configuring the GPIO in the powerstage protection block instead of routing the output of it? If so, did you get the same results?
You mention this but I just want to confirm - all of the blocks involved in this problem are on CPU1? Is your project configured for multiple CPUs?
Is there any factors in your circuit that could contribute towards unexpected phase delay? For example, is your digital output that you were measuring just running through a simple voltage divider, or is there more at play? Perhaps can the measurement be taken directly at the pins for the PWM and the digital out to confirm this is the issue?
Do you have measurements on the delay between the “trip signal” being activated and when the PWMs turn off? And subsequently the delay between the trip signal and when the digital out is turned off?
This is definitely a perplexing one! 40ms is a huge delay that even for bad case scenarios I’m surprised could be introduced.
So if possible, a screenshot of your scheduling tab in the Coder options menu would be helpful, and additionally if you can provide a pared down version of your model that shows the issue that you’re comfortable with, that would be very helpful for us to debug.
