• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 83 subscribers
  • Views 243 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.

TMS320F28379D: CPU2 CLA TASK Double-Executing, CPU2 EPWMs Corrupting CPU1 EPWMs

Jim Crawford
Prodigy 70 points
Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Tool/software:

I have CPU1 using EPWM4, 5, and 6 and working fine. When I have CPU2 using EPWM1, 2, and 3, however, two problems are occurring. On CPU2, CLA TASK1 does all of the work involving the EPWMs, but this task always executes twice for every cycle rather than once. Secondly, if EPWM1 is used, it corrupts the EPWMs connected to CPU1 in a very periodic repeated manner. By chance is there any example code using both CPUs and all of these EPWMs? Thanks. 

  • 0
    TI__Mastermind 20571 points

    Hi Jim,

    It sounds like you are running a dual core example. Is that correct? Can you confirm if you have mapped EPU1 exclusively to CPU2? 

    I would reference the dual core examples in C2000Ware https://dev.ti.com/tirex/explore/node?node=A__ANDL8U1U0CdQrcsu6kVbQg__C2000WARE__1kRFgrO__LATEST&placeholder=true 

    Regards,

    Ozino

  • 0 in reply to Ozino Odharo
    Prodigy 70 points

    Hi Ozino,

     

    I’ve run the TI dual-processor examples previously without issue. I’m having problems with my own code now. I have separate code/builds for CPU1 and CPU2. I’ve gone over my memory maps with a fine tooth comb to make sure there are no conflicts. The program on CPU1 runs perfectly in stand-alone mode. Even when I engage CPU2, two of the three CPU1 EPWM outputs are ok, but one of the EPWM outputs exhibits what can be rather severe “crosstalk” from the CPU2 EPWM(s). The interference pattern is periodic and constant unless I change the output frequency of the CPU1 EPWMs briefly. Due to this short-term frequency change, the interference pattern changes but then always settles into a fixed periodic interference.

     

    I’m running both CPUs along with their respective CLAs in my code. The single instruction which avoids this interference problem is if I do not update the Compare_A register on the master EPWM associated with CPU2. The EPWM base addresses are correct, however, and everything looks correct. CPU1 is using EPWM4, 5, & 6. CPU2 is using EPWM1, 2, & 3. Originally, I had EPWM1 be the master (for CPU2) but that’s when the EPWM-related CLA task always got executed twice per EPWM cycle. Making EPWM2 the master with EPWM1 & 2 acting as slaves somehow side-stepped that problem. I’m still not satisfied with the reasoning behind this though. But this cross-talk interference has me really stumped at the moment.

     

    The interference pattern gets superimposed (in an additive manner) to the signal which should be present. I can’t see any mechanism that would explain this.

  • 0 in reply to Jim Crawford
    TI__Mastermind 20571 points

    Hi Jim,

    Thanks for the explanation. I'm going to loop in our ePWM experts to chime in on the situation.

    Regards,

    Ozino

  • 0 in reply to Ozino Odharo
    TI__Expert 3800 points

    Hello,

    Issue 1: CLA TASK1 executing twice per cycle on CPU2

    This might be related to the way you've configured the EPWMs on CPU2. When you made EPWM2 the master and EPWM1 and 3 slaves, it's possible that the CLA task is being triggered twice due to the way the EPWMs are synchronized. You can try checking the EPWM synchronization settings and the CLA task configuration to ensure that the task is only executed once per cycle.

    Issue 2: EPWM corruption and crosstalk

     Given that you've checked the memory maps and ensured there are no conflicts, it's possible that the issue is related to the way the EPWMs are using shared resources or the way the clocks are configured.

    One potential explanation is that the EPWMs on CPU1 and CPU2 are sharing a common clock source or are synchronized to the same clock domain. If the clocks are not properly synchronized or if there's a phase difference between the clocks, it could cause interference or crosstalk between the EPWMs.

    Another possibility is that the EPWMs are using shared peripherals or resources, such as the same timer or counter, which could be causing the interference.