• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 82 subscribers
  • Views 688 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: When two Interrupt occurs on the same Group at the same time,

Shaoxing Ke
Expert 3590 points
Part Number: TMS320F28388D

Hi Experts,

If two interrupts of the same group are generated at the same time, the higher priority one will respond, but will the low priority interrupt flag be cleared? 

Customer are encountered the below condition:

ADCA1 and CIPC0 are generated at the same time, and PIEIFRx is set accordingly. If ADC_ISR is responded to CPU//ACK, will PIEIFR1.13 (CIPC0) be cleared?

Or Acknowledges group and clears any interrupt flag within group? 

If not,  are there other situations that would cause PIEIFR1.13 to clear? Thanks.

  • 0
    TI__Mastermind 19795 points

    Hi Shaoxing,

    Thanks for your question.

    Shaoxing Ke said:
    If two interrupts of the same group are generated at the same time, the higher priority one will respond, but will the low priority interrupt flag be cleared? 

    low priority interrupt flag will only be cleared if you clear that PIE interrupt yourself within the interrupt. You should only clear the PIE interrupts for the ISR you are in.

    Shaoxing Ke said:
    will PIEIFR1.13 (CIPC0) be cleared?

    Only if you clear the entire PIEIFR1. You should only clear PIEIEFR1.1

    Shaoxing Ke said:
    Or Acknowledges group and clears any interrupt flag within group? 

    ACK is separate from PIEIER and PIEIFR registers. See below diagram from a similar device TRM. It does NOT clear all PIEIFR interrupts within the group.

    Shaoxing Ke said:
    If not,  are there other situations that would cause PIEIFR1.13 to clear? Thanks.

    The only thing that can clear PIEIFR is manual clear on exit from that ISR.

  • 0 in reply to Vince
    TI__Expert 3590 points

    Hi Vince,

    Double confirm, ACK does NOT clear all PIEIFR interrupts within the group. 

    And then manual clear PIEIFR1.1x on exit from that ISR. But actually we found that we always trigger CIPC0 interrupt, but the PIEIFR1.13  is not set automatically. (Bule: ADC_ISR; Yellow:DMA_ISR; Purple: IPC_ISR). You can see the IPC_ISR will not happen normally. 

    So, PIEIFR1.13 What conditions will be set? PIEIFR1.13 What conditions will be cleared? 

  • 0 in reply to Shaoxing Ke
    TI__Mastermind 19795 points

    Hi Shaoxing,

    Shaoxing Ke said:
    So, PIEIFR1.13 What conditions will be set?

    The only thing that will specifically set the PIEIFR1.13 bit is the peripheral itself. In this case, the CIPC0 peripheral setting the PIEIFR1.13 register.

    Shaoxing Ke said:
    What conditions will be cleared? 

    Once it is set the only things that clear it are:
    1. Manually clearing PIEIFR register for that bit.

    2. Returning from an ISR for that interrupt. Example returning from interrupt x.y clears PIEIFRx.y

    So it should not be clearing unless one of the two above is occurring.

    Are you using nested interrupts by any chance? If so, you may not realize that the CIPC0 interrupt is occurring within the ADC interrupt (or vice versa).

    Regards,

    Vince

  • 0 in reply to Vince
    TI__Expert 3590 points

    Hi Vince,

    Yeah, we use nested interrupts, ADC_ISR and DMA_ISR, as below:

    We have several interrupts as below setting:

    Interrupt name

    PIE Group and index

    Priority

    Comments

    DMA ISR

    7.1

    1 (highest)

    Highest priority, 72 kHz freq

    ADCA ISR

    1.1

    2

    Will nest by DMA ISR, 36 kHz freq

    EPWM1 TZ Interrupt

    2.1

    3

    Call ProcessA2D_HWI in every 8 ADCA ISR, (4.5 kHz freq).

    Will nest by DMA ISR and ADCA ISR.

    EPWM1 Interrupt

    3.1

    4.1

    Software interrupt, call InverterZeroCrossing (50 Hz freq)

    Will nest by DMA ISR and ADCA ISR.

    EPWM2 Interrupt

    3.2

    4.2

    Software interrupt, call UtilityZeroCrossing (50 Hz freq)

    Will nest by DMA ISR and ADCA ISR.

    Timer 2 Interrupt

    14

    0

    FreeRTOS Tick Timer

    And also we use IPC_ISR as above. So is it reasonable？

  • 0 in reply to Shaoxing Ke
    TI__Mastermind 19795 points

    Hi Shaoxing,

    Shaoxing Ke said:
    And also we use IPC_ISR as above.

    I'm not sure what you mean by this, can you clarify?

    Either way, anytime the IPC_ISR occurs and returns, it will clear its own flag. That seems like what is happening here.

    Regards,

    Vince

  • 0 in reply to Vince
    TI__Expert 3590 points

    Hi Vince,

    When the same group interrupt occurs (ADC_ISR and IPC_ISR )simultaneously, The one with higher priority-ADC_ISR CPU will respond, and the flag with lower priority-IPC_ISR will be saved. Right?

  • 0 in reply to Shaoxing Ke
    TI__Mastermind 19795 points

    Hi Shaoxing,

    Shaoxing Ke said:
    When the same group interrupt occurs (ADC_ISR and IPC_ISR )simultaneously, The one with higher priority-ADC_ISR CPU will respond, and the flag with lower priority-IPC_ISR will be saved. Right?

    Correct. This is the case. The reason I'm asking about your nesting specifically is because none of the ISRs in your table above mention what is being done with IPC_ISR.

    You have to make sure you allow IPC_ISR to occur within the other ISRs.

    Regards,

    Vince

  • 0 in reply to Vince
    TI__Expert 3590 points

    Hi Vince,

    We suspect this point. But when we comment the interrupt nest between ADC_ISR and DAM_ISR, IPC_ISR still does not generate sometimes. It can be determined that the IPC interrupt condition is triggered periodically. So I will email to you for debug this case here. Thanks.

  • 0 in reply to Shaoxing Ke
    TI__Mastermind 19795 points

    We are following up on this thread offline. The IPC expert will be assisting with this.

    Regards,

    Vince

  • 0 in reply to Vince
    TI__Mastermind 19795 points

    As an update to this thread, we have taken this thread offline with Vivek Singh.

    We have verified the issue only occurs when an IPC command is issued from one CPU to another, and the interrupt occurs at the same time as another interrupt in the group. At this point, the IPC flag is ready but it looks like the IPC command is not setting the PIE flag.

    We have tested that this does not happen with the PIE, as we created a test to see if two PIE interrupts in the same group occurring at the same time (and also nearly the same time) would replicate the issue.

    Next steps are Vivek is planning to test this himself locally and will work with design to determine what could cause this (possibly asynchronous calls to the PIE group at the same time, etc.).

    Closing this thread now as debug is done offline.

    Regards,

    Vince