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.
Tool/software: Code Composer Studio
Hello,
I am running an ac-dc converter which requires the phase-shift between its two half-bridges to be modulated to perform PFC. The PWMs are supposed to be of 50% duty ratio all the time. However, as shown in the attached image the PWM for one of the legs remains spuriously high for the entire switching period (happens a few times every line cycle) resulting in malfunctioning of the converter. The other leg's PWM works fine throughout. Any comments or suggestions to mitigate this issue is appreciated. Thanks.
Hi,
Are you synchronizing the PWMs and loading a phase shift (via TBPHS)?
When you synchronize the PWM there a possibility of sudden change in the PWM time base as the TBPHS gets loaded.
This could result in missing compare pulse - if the PWM time base jumped over the compare value and compare event is missed.
You can check the the phase being loaded and the compare values being used for PWM generation and make sure such a condition is avoided.
To ascertain if that is the issue, you can monitor the phase values and compare values being applied.
Since you said, it's 50% duty, i presume compare value is also the same. In which case you monitor the phase variable only and make sure then loading phase compare event is not missed.
Hi,
Yes, the PWMs are synchronized and the compare value is fixed at half of the TBPRD value. When you say monitor the phase variable, how do I monitor it at at such a high frequency (typically I can monitor a variable only at around 10 samples/ sec)? Moreover, it is unclear to me what exactly I should be looking for while monitoring this. Could you please clarify? Also, by sudden change in time base, do you mean the period value(TBPRD) changes suddenly?
Hi,
You already know the compare value as it's fixed for 50% duty.
You would know the value of phase you are writing. You would also know the current value of the counter based on when the synchronization pulse is expected to happen. So, make sure that the expected change in the counter value due to phase loading is such that compare value is not missed.
For example, say,
compare value is 10
TBPHS = 15
current counter value (when sync pulse expected to arrive) = 5
In this case counter will jump from 5 to 15 and miss the compare event at 10.
So, you should update the phase value based on expected counter value when the sync pulse arrives - such that the jump in the counter should not make you miss the compare event.
Hi,
You can also refer to other form posts below where similar issues are addressed.
https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/814513
https:// https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/317898
Diagram below shows the problem clearly
http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/171/8130.Multi_2D00_phase-Variable-Frequency.pdf
This is a variable frequency case. But it is also applicable to variable phase - similar to your use case.
Hi,
I understand the issue. Would it be possible for you to share a sample code that resolves this (or any equivalent) issue?
Hi,
I made sure that the counter doesn't skip the compare value by lowering the compare value slightly under such a condition (although now duty is slightly less than 50%, but that is manageable). However since compare value is loaded in shadow mode and phase value is not, the problem persists. can you suggest a way around?
Hi,
Mausamjeet Khatua said:However since compare value is loaded in shadow mode and phase value is not, the problem persists.
Hi,
No. The new CMPA is less than the CMPA corresponding to 50% duty, which again leads to a skip event.
Hi,
You need to change the value of CMPA based on the phase you are loading so that the event is not skipped.
CMPA should be set back to 50% when you do not anticipate the skip event. Otherwise, you are simply moving the issue to a different CMPx/TBPHS value combination.
Hi,
You are right. I tried ensuring that. Even then also I was not able to resolve the issue fully (although the frequency of such spurious events dropped drastically). Previously the sampling frequency and the switching frequency did not have any correlation. keeping the switching frequency at integral multiples of sampling frequency helped fully resolve the issue.
Hi, Good to know that you are able to resolve the issue. Let us know if you've any additional questions.