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.

Nested Interrupts with F28335

Hallo,

I have implemented a motor control system with a lot of interrupts. I run a FOC system attached to the EPWM-Modul, interrupt function ic connected to the EPWM1_INT in PIE-Group-3 (all 20µs)

To get always new Motor-Current informations, the ADC is connected to the MCBCP-B with DMA service on Channel DMA-6, DINTCH6 Interrupt PIE-Group-7.

The main controllers like Speed are running in Timer-0 Interrupt with TINT0 of PIE-Group-1 (all 200µs)

Both lower priorised Ints EPWM1 and DINTCH6 should always be service, although during a running TINT0 inetrrupt routine.

This works fine with the EPWM1, but from time to time the DINTCH6 is not able to interrupt the TINT0 of Timer-0.

This means, the FOC function has no actual Motor-current value.

I have the following code in the TINT0 interrupt function, following the SPRUFB0D.PDF:

    Uint16 TempPIEIER;
    TempPIEIER = PieCtrlRegs.PIEIER1.all; // Save PIEIER register for later
    IER |= 0x0044;                         // Set global priority by adjusting IER
    IER &= 0x0044;                         // Allow EPWM1_INT and DINTCH6
    PieCtrlRegs.PIEACK.all = 0xFFFF;      // Enable PIE interrupts
       asm(" nop");
    EINT;                                 // Clear INTM to enable interrupts

What else can prevent the DINTCH6 from interrupting the TINT0 routine?


   

  • Ralf,

    I think this line is a typo:

     PieCtrlRegs.PIEACK.all = 0xFFFF; // Enable PIE interrupts

    I think you mean instead:

     PieCtrlRegs.PIEIER1.all = 0xFFFF; // Enable PIE interrupts

    Regards,

    Bill

  • Ralf,

    perhaps this is a problem of interrupt priorities. In an abstract general approach and in the absence of any tasks manager a system with many interrupts will behave predictably if interrupts of shorter time periods have higher priorities and interrupts of longer time periods have lower priorities. Otherwise, the system may behave unpredictably. And certainly one needs to remember another rule for multi-interrupts system http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/269497/941465.aspx#941465.

    Regards,

    Igor

  • Hallo Igor,

    the Ints have the following timing:

    TINT0 -> all 200µs -> 5-10µs

    EPWM1_INT -> all 20µs -> 6,5µs

    DINTCH6 -> all 20µs -> 200ns (DINTCH6 will appear exact 5,5µs before EPWM1_INT)

    This code at the beginning of the TINT0-Interrupt is as effective as the first I've posted:

    interrupt void HwiTimer0(void)
    {
        // Int runs every 200µs
        // read: http://processors.wiki.ti.com/index.php/Interrupt_Nesting_on_C28x
        // Global Disable all Interrupts
        DINT;
         // Enable CPU int3, hier EPWM1_INT
        IER |= M_INT3;
        // Enable CPU int7, DMA6 Analog Current Measure
        IER |= M_INT7;
        // Acknowledge this interrupt to receive more interrupts from group 1
        PieCtrlRegs.PIEACK.all = 0xFFFF;      // Enable PIE interrupts
        // Enable global Interrupts and higher priority real-time debug events:
        EINT;   // Enable Global interrupt INTM
        ERTM;   // Enable Global realtime interrupt DBGM

    At least, the system works, but some of the DINTCH6 do not appear.

    Could this be happen, when the TINT0 and the DINTCH6 appear exact at the same time?

    Ralf

  • Hallo Bill,

    at this time I do not need any other INT from PIE-Group1, so I commented

    out this line from the WIKI example. (http://processors.wiki.ti.com/index.php/Interrupt_Nesting_on_C28x)

    The behaviour is the same.

    Ralf

  • Ralf,

    Ralf Koester said:

    Could this be happen, when the TINT0 and the DINTCH6 appear exact at the same time?

    Yes, I suspect it happens sometimes. These two interrupts are asynchronous. At least I do not find any other explanation for such behavior. Sometime ago I dealt with software development for some another core and a system had 5 asynchronous interrupts. Only the correct priorities statement (like my above post)  has allowed to get a predictable behavior. But maybe I'm wrong at your special case.

    Regards,

    Igor