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.

TMS320F280025: Global load general abnormal waveform while update close with counter zero

Part Number: TMS320F280025


Tool/software:

customer set PWM logical as below:

1,  PWM1 general sync signal by counter zero event to PWM4, both PWM1 and PWM4 clear count and update register by sync event

2,  PWM1 and PWM4 both set to Global one-shot load with counter zone event, and PWM4 link to PWM1

3,  Timer0 general 40Khz interrupt to update PWM frequency and duty for PWM1 and PWM4 then trigger global one shot load

If step 3 code execute as below will general abnormal waveform

 

if step 3 code modify as below to avoid update close with counter zero, then pwm waveform always run well

Below is the PWM1 and PWM4 setting code, could you please help review if anything setting missing to cause the issue?

    

  • Terry,

    Following thread is discussing the same issue that you have reported which is ongoing and we have assigned expert to look into this. Is it possible to follow the same thread?

    https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1486535/tms320f2800137-f2800137-global-load-of-aqctla/5811883

    Regards,

    Sumit

  • Hi Sumit

    Thanks your advice, I have a look for the post your advice, it seem there issue while PWM Period enable hi-resolution adjustment then using global loading function. However my case has not enable the hi-resolution for PWM Period, and Fix ISR frequency is slower than PWM frequency, could you help double review whether my case is same issue root cause ?

  • Hi Sumit

    Customer has disable all Hi-Res configuration as below, and still meet abnormal waveform if set OSHTLD = 1 while PWM count close zero.

    Do you have any update finding for this behavior?

  • Terry,

    It seems there are some restrictions and considerations when using the global load with certain register values:

    1. A dead band value of zero cannot be used when the global shadow to active load is set to occur at counter zero (CTR=ZERO).

    2. Similarly, a dead band value equal to the period (PRD) cannot be used when the load is set at CTR=PRD. This can cause abnormal waveform generation.

    3. When the DBRED/DBFED active register is loaded with a new shadow value while the dead band counters are counting, the new value only affects the NEXT PWM edge and not the current edge. This can also lead to unexpected waveform behavior if not accounted for.

    To resolve this, If the compare values (CMPA/CMPB) are loaded on counter zero, they must be greater than or equal to 1. If CMPA/CMPB is 0, the PWM output will be stuck low for the entire period. If the compare values are loaded on the period value, they must be less than or equal to TBPRD - 1 to avoid having a very short pulse that may be ignored by the system. The global load feature allows the shadow registers for TBPRD, CMPA, CMPB and other values to be updated simultaneously on a defined load event, such as counter zero or period. However, if the compare values violate the constraints mentioned above when using global load on counter zero, it can lead to distorted or missing PWM pulses in the output waveform. 

    Could you please try these remedies to see if that resolve you issue?

    Regards,

    Sumit

  • Hi Sumit

    Thanks your advice, we do the test by modify dead band value to be non-zero, and ensure CMPA/CMPB value under right range, however still meet the same issue PWM waveform if Global update around counter zero point. Only if we do Global update away of counter zero, the waveform could run well.

  • Terry, 

    If doing global update away of counter zero, the waveform could run well then could you please confirm if these waveform are synchronized using TBPHS/TBPHSHR register? Maybe that's where the problem could be. Please note that synchronization using this register has 1-2 CPU cycle of delay and that need to be accounted.

    Regards,

    Sumit

  • Hi Sumit

     No customer donot use TBPHS/TBPHSHR, only update period and comp. I have already upload the customer code in this post, you could check the code in detail

  • Hi Terry,

    Perhaps be concerned with CPUTM0 one shot load CMP-A/B not being synchronous TBPRD clock. Where is CPTM0 function code in this thread?

    Consider CPUTM0 can overflow; should be tested and overflow cleared in the function loop. If CPUTM0 is an ePIE interrupt event source, it should give priority to EPWM ISR event handler, if one exists? And global updates via CPUTM0 one shot event loads shadow registers (CMP-A/B) with duty cycle update counts constrained by ADC samples. Typically, the ADC interrupt is used to monitor current regulation in PWM driven inductors. Also, the EPWM ISR event source trigger for ADC samples conversion timing loop and controlling duty cycle for precision current regulation in secondary inductor/s.

    Regards, 

  • Hi Genatco

    Sorry I cannot understand your meaning what issue happen if not priority to EPWM ISR and constrained by ADC sample? could you please help advice in more detail?

    You could check the CPUTM0 function code and the abnormal PWM waveform in the begging of this post.  If CPUTM0 function code do global update without avoid PWM zero count, the PWM waveform will general abnormal twice pulse in one period. I think even the ADC sample wrong and calculate wrong duty, it should not cause PWM abnormal twice pulse, so I believe it should be only PWM module update issue

  • Hi Terry,

    3,  Timer0 general 40Khz interrupt to update PWM frequency and duty for PWM1 and PWM4 then trigger global one shot load

    The function code CPUTM0 ISR routine is not shown above. Seemingly should give priority ePWM ISR/ADC SOC handler, check TRM analog sub section tables, review ISR priority order. The while loop delay (workaround) seems to suggest CMP-A/B oneshot load has a timing issue with ePIE IRQ pending and CPU busy delaying stack push / pop operations. Also verify adequate stack space exists for ePIE operations CPUTM0 and clear the timer overflow flag after ISR entry. 

    Regards,