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.
Hello support,
I have a question about the behavior of the Blanking Window when it crosses the CTR = 0 or CTR = PRD boundary.
I see in the description of the register DCFWINDOW that the BW can be cut under certain conditions (underlined in red).
This is what we also have experienced.
But I see also a mismatch between this behavior/description and last case shown in diagram at par. 22.14.4.2 of TRM
Since here the BW(n) is active when the Offset(n+1) expires, I expect that the counter is not restarted and the BW is cut at the end of BW(n), where I have drawn the red line.
What do you think ?
Hi Davide,
To clarify, you have observed a scope shot that corresponds with the red line you drew in this diagram? If this is the case, we will test this on our side and confirm whether this figure is inaccurate.
Thank you,
Luke
Hello Luke,
I try to summarize how we use Blanking Window and what we observed.
We generate 2 pwms from 2 different peripherals (one channel per peripheral): PWM13B and PWM2A
They are both configured as UP-DOWN counters and counter of PWM2A is in phase with counter of PWM13B.
PWM13B is HIGH from ZERO to PERIOD, PWM2A is HIGH from PERIOD to ZERO (see picture)
Blanking window is configured only on ePWM13.
We use the signal EPWM13BLANK (path red line in the picture below) to enter a CMPSS and inhibit a TRIP signal that acts on both PWM13B and PWM2A.
Blanking Window starts on ZERO and PERIOD, and has OFFSET = 0
When we set the TRIP condition as ACTIVE, we observe the following (see pictures):
if the BW < PERIOD, both PWM signals are as expected, their duration is the same as the BW --> when the BW is over, the PWMs are cut by the TRIP condition.
on the other hand if the BW > PERIOD, PWM13B is ok but PWM2A is cut at the end of the BW (that started when the counter was ZERO): it seems like the BW is not restarted at PERIOD (and this seems to be consistent with the description of register DCFWINDOW)
Our last use case (with BW crossing PERIOD boundary) seems to be very similar to the third case shown at par. "22.14.4.2 Event Filtering" of the TRM, but with the difference that in TRM picture the BW seems to be restarted at the end of "Offset(n+1)", and this is inconsistent with the description of register DCFWINDOW.
Hi Davide,
Thank you, I better understand this issue now. Can you confirm that your DCFCTL[PULSESEL] value is 10? I have contacted the design team to confirm that the TRM's description of two overlapping blanking windows is correct, I will get back to you as soon as I get a response.
Thank you,
Luke
Yes,
I load into DCFCTL[PULSESEL] the value EPWM_DC_WINDOW_START_TBCTR_ZERO_PERIOD = 2
Hi Davide, the design team has gotten back to me and they believe this is related to a known issue with the blanking window feature. I will test a similar configuration to yours on my end tomorrow morning to confirm the root cause. Please expect a response back by end of day tomorrow.
Thank you,
Luke
Hi Davide,
I've confirmed that the register description and this figure is incorrect. Here is the correct figure that matches the behavior described in the register description, which will be included in the next revision of the technical reference manual:
Note that if the offset of the upcoming blanking window expires at the same time as the current blanking window expires, the new blanking window will not be ignored. This is shown in the bottom waveform of this figure.
Thank you,
Luke