• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 321 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.

TMS320F28388D: PWM Sync between PWM's is generating extra ISR Interrupt

Dorion Carr
Prodigy 210 points
Part Number: TMS320F28388D

Tool/software:

Hi,

  I have 4 PWMs in use.

  PWM8 is running on CPU1, PWM1,3,5 are running on CPU2. PWM8 ISR on CPU2 is tied to CPU2/CLA Task 1 ISR.

  PWM8 is the master synchronization (in the future I need PWM8 to sync to EtherCAT Sync0 pulse).

  PWM1 is tied to the output signal from PWM8 and PWM3&5 are tied to PWM 1 output signal

  PWM1 is running at 50 and PWM8 is running 4 times slower at 200.

  PWM8 is counting UP, PWM1,3,5 are counting up/down.

  When PWM8 hits 0, I want PWM1 to sync to 0, which in turn causes 3&5 to sync to 0 and  PWM1 0 count cause an interrupt to the processor.

  I have enabled all the PWM's here and I have shadow mode enabled.

  I can see when PWM8 hits zero that PWM1 goes to zero and causes the ISR, so I know that they are in sync.

  Where I am running into an issue is the following:

  1. If we are configuring the system I have a flag in PWM1 ISR handler to pretty much just ack the ISR signals and leave.
    1. All the PWM's are running we just don't do anything when we get the PWM1 ISR until configuration is done.
  2. When configuration is done and when the CLA Task 1 Finished ISR is called (for the first time) it will enable the flag (in item 1)
  3. On the next PWM1 ISR we will process data. I see that when this is enabled that we get an ISR about 1 USEC later and we process the ISR normally. I am looking at the counters.

  What happens next is odd. We will get another PWM1 ISR where the PWM Counts are 18 useconds later instead of being close to zero.
  We should only be getting an ISR when the counters are zero in PWM1,

  There doesn't appear to be anything pending.

  Is there any reason why this would happen?

  • 0
    Prodigy 210 points

    Hi Does anybody have any suggestions?

  • 0 in reply to Dorion Carr
    TI__Expert 3240 points

    Dorion,

    We are checking internally about this issue and will get back to you in early next week.

    Regards,

    Sumit

  • 0 in reply to Sumit Patil1
    TI__Expert 3240 points

    Dorion,

    Is your GTBCLKSYNC/TBCLKSYNC being set in their Device_innit() before their PWM initalizations? Execution timewise, when does it get set?

    Regards,

    Sumit 

  • 0 in reply to Sumit Patil1
    Prodigy 210 points

    Sumit,

      We are using TBCLKSYSNC and they are both being set at startup on each CPU.

      The issue seems to happen when we "touch" either PWM8 later on (PWM8 is the overall sync controller running on CPU1) and/or PWM1 which is the secondary controller on CPU2 that has 2 other PWM's sync'd to it.

      What I mean by touched is if we enable/disable the ISR to the processor for PWM8 (let the PWM continue to count) or changes it sync mode ect.

      If I don't disable the ISRs but use a flag to process the interrupt at the processor and just ACK the ISR then the issue doesn't seem to happen just if I touch the PWM. I thought maybe it was enable/disable ISRs that maybe was doing it but it seems to get the first sync pulse and correct ISR at the processor but the second one seems to come faster.

      Could this have anything to do with touching the PWM and it causing a caching load into the PWM registers?

  • 0 in reply to Dorion Carr
    TI__Mastermind 25446 points

    Hi Dorion,

    Dorion Carr said:

      What I mean by touched is if we enable/disable the ISR to the processor for PWM8 (let the PWM continue to count) or changes it sync mode ect.

    What is the use case behind doing this? What specific bits are you updating during run time? Are you enabling / disabling the ISR to process from PWM's register's ETSEL?

    What is your counter mode after synchronization set to? If you're phase shift, could be this configuration causing a ZRO event to happen earlier depending on your SYNC scheme.

    Best,

    Ryan Ma

  • 0 in reply to Ryan Ma
    Prodigy 210 points

    Hi Ryan,

    The reason we do this is the following:
    1. When we go into a configuration of our system we stop PWM8 and PWM1 ISR (counter = 0) to the processor so that we can do the configuration changes.

    1a We want the PWM's to stay in sync so we do not stop the counters we just let the run and continue to sync. Remember PWM8 is running at 125 usecs and PWM1 is running at 31.25usecs. Basically we don't want the associated ISR in the process to run anything while we are configuring.

    2. Once we know when configuration is done we just re-enable the ISR to the processor for PWM8 and PWM1. It doesn't matter where the PWM counter is as long as we get the ISR at count = 0. What we see is that both PWM's will fire at count=0 and then sometime later where the counter is like 1-3 usecs later.

    Could this be caused by some caching and/or start and stopping of the PWMs?

    PWM8 synchronization is zero and PWM1 is synchronized to PWM8. PWM8 could be setup to Sync0 at some point.

    Well I am OK if the phase shifting is causing a ZRO event to happen earlier but why would we get another one 1-3 usecs later?

  • 0 in reply to Dorion Carr
    TI__Mastermind 25446 points
    Dorion Carr said:
    Could this be caused by some caching and/or start and stopping of the PWMs?

    It could be that since the previous zero event has occurred, then you're renabling the interrupts, the current event zro interrupt must get serviced, but another event has occurred and you receive one 1-3 usecs later.

    Can you double confirm when this issue occurs by using OUTPUTXBAR to route out the ZRO event of PWM1's to a GPIO? Does this ZRO event happen periodically and as expected? If so, I believe the interrupt servicing, and when another interrupt occurs may be due to when the phase shift occurs between both PWMs.

    Best,

    Ryan Ma

  • 0 in reply to Ryan Ma
    Prodigy 210 points

    Ryan, 

     Yes I will do the output to a GPIO, but it will have to wait about 1 week.

     Before enabling the ISRs I clear all PWM and CPU interrupts. So unless the timing of doing these statements are longer than 125 usecs or 31.25 usecs I don't see how I am getting the interrupts for the last zero count. This also wouldn't explain why I would get another one 1-3 usecs later.

    Could you please explain this statement?


    "If so, I believe the interrupt servicing, and when another interrupt occurs may be due to when the phase shift occurs between both PWMs."

    Why do you think that?

    Dorion

  • 0 in reply to Dorion Carr
    TI__Mastermind 25446 points

    Hi Dorion,

    Apologize I have been busy with some other tasks. 

    With phase shift, depending on the value being written to TBPHS, may have caused a jump to generate another interrupt. That is why I want to see when the ZRO events are occurring from PWM8 that may be causing an additional interrupt to get generated. Once we know if PWM8 is generated an additional ZRO event trigger then we can diagnose what is happening for the extra ZRO event to occur. Otherwise if we do not see PWM8 generate another ZRO event sync, and PWM1 receives a random sync signal, are you sure the software phase shift is not enabled?

    Can you double confirm that TBCTL.SYNCOSEL for PWM8 is configured to be 01.

    The EXTSYNCOUT can help give us reference as when the interrupts are getting generated.

    Best,

    Ryan Ma