• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 83 subscribers
  • Views 497 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28032: AQCSFRC cannot pull EPWMxA low by software?

Shaoxing Ke
Expert 3590 points

Part Number: TMS320F28032

Hi Experts,

I am asking for my customer here.

Customer are encountering the AQCSFRC cannot pull EPWMxA low.

They use S/W to write "0x1" to AQCSFRC.CSFA on EPWM1, EPWM2, EPWM3, and find that only EPWM2 cannot pull EPWM2A low, other EPWM1A, EPWM3A are right. EPWM2A would be always high, But after about 200ms, EPWM2A can become low level by AQCSFRC.CSFA. Due to the fault was discovered by the end customer, it is impossible to locate the issue through hardware method.

So, we check the below step:

#1.F2803x ADC sampling and communication can work normally, system clock is normal.

#2.We use 20ms interrupt to read the register value of EPWM. Like EPWM1.TBPRD, EPWM2.TBPRD, EPWM3.TBPRD both right 3000, AQCSFRC both "0x01", EPWM2.TZFLG = 18; EPWM2.TZCTL = 2, GPIO_DATA about the PWM output pin, PWM1A is 0; PWM2A is 1; PWM3A is 0. So, PWM2A is not normally pulled low.

#3.We check the loadmode about AQCSFRC, load on event counter equals zero.  We would check the Zero Event whether to generate.

#4.We check the TZ configuration code, found that EPWM2 CBC and DCAEVT2 generate.

#5.it will be phase shifted between PWM1A, PWM2A, PWM3A. PWM1A is master, and Phase Shift 120° to PWM2A, Phase Shift 240° to PWM3A.

Is it the phase shift that is causing the zero crossing event to be lost for a long time?  Are there other reasons? Any suggestions for other software exclusions? Thanks a lot~

  • 0
    TI__Expert 7210 points

    Hi,

    Shaoxing Ke said:
    Is it the phase shift that is causing the zero crossing event to be lost for a long time?  Are there other reasons? Any suggestions for other software exclusions?

    Can you try plotting both the AQCSFRC signal and PWM on the scope and see whether the AQCSFRC is correctly generating or not? Phase shift can cause the TBCTR value to change, but I believe the phase shift is remaining constant at 120 / 240 so that shouldn't cause a big issue.

  • 0 in reply to Aditya Dholakia
    TI__Expert 3590 points

    Hi Experts,

    Customers cannot reproduce this fault in the laboratory, and cannot use hardware troubleshooting methods under outdoor conditions.

    By viewing the information using SCI, the AQCSFRC register is normally set to "0x1", EPWM1A and EPWM3A can be pulled down normally immediately, and it takes about 600ms for EPWM2A to be pulled down.

    You can see the AQCSFRC right, TBPRD right, TZFLG and TZCTL right. GPIO_DATA refer to EPWM2A output pin, In fact, EPWM2A is not pulled down immediately, but pulled down after 600ms. 

  • 0 in reply to Shaoxing Ke
    TI__Expert 7210 points

    Hi,

    Few more questions:

    1. Is the delay of 600ms is consistent?

    2. Is there any observation where the delay comes for EPWM3A as well? If this is the case then probably phase loading might be one of the reasons, otherwise the reason could be something else.

    3. Can you share the initialization code so that I can try to recreate the issue on my end?

    Thanks,
    Aditya

  • 0 in reply to Aditya Dholakia
    TI__Expert 3590 points

    Hi Aditya,

    Sorry for the late reply, just finished vacation.

    I will confirm these with the customer and get back to you. Thanks a lot~

  • +1 in reply to Shaoxing Ke
    TI__Expert 3590 points

    Hi Aditya,

    The reason for EPWM2A  abnormal wave has been found. Due to the loss of the Zero event caused by SYNC, EPWM2A was not pulled down when CTR= 0. 

    We suggest customers to disable the SYNC, and then perform the AQSFRC action. Do you have any other suggestion here? Thanks a lot~