• State
  • Replies 3 replies
  • Subscribers 83 subscribers
  • Views 98 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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__Genius 17962 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__Genius 17962 points

    Hi Jim,

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

    Regards,

    Ozino