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.

AM2634-Q1: Strange phenomenon on the EPWM2 PRD sync load

Part Number: AM2634-Q1

Hi BU, 

Customer side has an issue regarding to EPWM2 PWM output. In their design, they use EPWM1 as sync source (EPWM1 CTR=ZRO), and EPWM2/EPWM3's PRD shadow load event is this sync signal and PRD is also linked to EPWM1's PRD. EPWM1/2/3 will have frequency/period suddenly change and slowly change (i.e. 40kHz suddenly change to 60kHz, and 60kHz slowly change to 40kHz). And the EPWM2's configuration codes are as follow. Notes the action qualifications are CMPB-Down pull-up and Zero pull-down. 

During suddenly changing the frequency, i.e. 40kHz -> 60kHz, sometimes the PWM2' output will not change. A 25us background task read out the CTR and PRD value of EPWM2, and if the CTR is larger than PRD, one GPIO will be pull low. As shown in following figure (the purple signal is the GPIO), when the PWM output not change, detected that the CTR value is larger than the configured PRD value.  And in the figure there is an measuring signal of the frequency for the PWM output (yellow signal is PWM2's B output, and the measuring frequency is over the yellow signal). As you can see, the issue is happened when suddenly changing the frequency from 40kHz to 60kHz, not each time but accidentally. The PWM output missing means that the CTR = CMPB-Down event missing from the AQ configuration

We tried a lot things, such as disable the phase-shift, etc., but not work. Finally, we found that if during suddenly changing PRD of the PWM2, we give a larger CMPB value (>100, for example) firstly, and then step-by-step reducing the CMPB value to the expected small value, the above issue can be avoid: 

I think the issue maybe caused by EPWM2 PRD shadow load action sometimes not work and CTR-CMPB down event missing and also CTR value will larger that the configured PRD value (we tried using CTR=CMPB-up event to pull up the output, and it works). The concept is shown in following figure: 

So questions are why PRD shadow load not action, and why if we configure a larger CMPB value this issue can be avoided. 

Regards, 

Will 

  • Hello Will,

    Sorry for the delay in reply but there was a lot of detail here so I wanted to take time to carefully unravel it. I am not certain I have a full understanding, but I will outline what I believe you are doing and where I think the issue is with the understanding of how the module works. Please let me know if I am mistaken at any point with my understanding of your setup.

    Setup:

    • EPWM1 is used as the Source of AQ Trigger Events T1/T2 for EPWM2/3.
    • EPWM1 counts down and when its zero, it shadow loads from the shadow register to active register
    • If this occurs when the CTR value is greater than the new PRD value being loaded from the shadow register, then you do not observe a change in PWM2 output
    • Your expectation is that when a PRD is loaded that makes CTR > PRD, the CTR = CMPB-Down event would occur.

    If I have that all right...

    My understanding of how the device is expected to operate:

    • The EPWM is configured for Counter Mode Up Down to start
    • The EPWM is configured for Counter Mode Up after sync
    • Because the issue occurs following a shadow load that is a sync event, when the issue occurs, the EPWM is operating in a state where it is in Up-Count Mode
    • Because the new PRD has been loaded when CTR is larger, it is not possible for a CTR = PRD Match to occur
    • Therefore no AQ events are triggered and the output does not change as expected
    • Lastly, when configuring with a larger CMPB value, that created a situation where the CTR can hit the CTR = CMPA event which when counting up should prompt a Low action from the EPWM

    One piece I don't understand is why there is a notion that the CTR = CMPB-Down event would occur. I'm not following the logic towards that expectation given the configuration explained.

    Best Regards,

    Ralph Jacobi

  • Hi Ralph, 

    This problem is complex to explain, but from my debugging in customer field, this problem maybe caused by conflict between EPWM group interconnection and the EPWMx register shadow loading. The reason is: 

    1) if I reduce some register accessing in the 25us ADC ISR, no matter what registers for EPWM2, this problem will not happen anymore. 

    2) if I change the EPWM2's group to G1, while other EPWM modules still maintain G0, the EPWM2's PRD shadow loading will be fine, however the EPWM3 (linking to EPWM1 PRD) will have this problem. 

    It is complicate to show you what I found, because customer will not share the codes. So maybe I need to call you when I am in customer field. 

    But before that, I need your help that please check internally that when R5 core accesses the Gx PWM register group for a EPWM module, will this action impact the shadow loading action in EPWM IP? The following figure is the interconnection for EPWM. 

    Regards, 

    Will 

  • Hi Will,

    Thanks for the added details and understand on the potential of needing a debug call. I'll reach out to you offline regarding that.

    But before that, I need your help that please check internally that when R5 core accesses the Gx PWM register group for a EPWM module, will this action impact the shadow loading action in EPWM IP? The following figure is the interconnection for EPWM. 

    I've sent this question to one of our experts who can better comment on this and we will get back to you with their feedback shortly.

    Best Regards,

    Ralph Jacobi

  • Hi Will, 

    But before that, I need your help that please check internally that when R5 core accesses the Gx PWM register group for a EPWM module, will this action impact the shadow loading action in EPWM IP? The following figure is the interconnection for EPWM. 

    I'll check on your last question here and get back to you. 

    Thank you,

    -Randy

  • Hi Will, 

    We got some info over the weekend from our design team. I think we have a usage/workaround that should eliminate this issue, but I need another day or so to get some confirmation. I'll update again tomorrow. 

    Thank you,

    -Randy

  • Hi Will, 

    Closing this thread as you have posted the root cause from the customer in email. 

    Thank you,

    -Randy