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.

F28335: temporarily disable interrupt in main loop

In the main loop of my application I need to copy data into tmp_buf. I wish to disable an interrupt (masked by M_Int1ms) that is likely to modify data while it is being copied. Other interrupts should continue to be serviced while memcpy() is executed.

Is the following code a safe way to achieve this?

  IER &= ~M_Int1ms;
  memcpy(tmp_buf, data, len);
  IER |= M_Int1ms;

Regards, Johannes

  • Hi Johannes,

    Johannes L. said:

    Is the following code a safe way to achieve this?

      IER &= ~M_Int1ms;
      memcpy(tmp_buf, data, len);
      IER |= M_Int1ms;

    Check this out:

    Regards,

    Gautam

  • Johannes, Gautam,

    Setting the INTM bit will disable all maskable interrupts.  Since Johannes wants to disable only a single interrupt, he does not want to do this.

    Recall the progression of interrupt enables on the C28x:

    peripheral int enable -> PIE -> IER -> INTM

    Most peripherals do not have an individual interrupt enable bit in their registers anymore.  Johannes did not say what  interrupt he needs to disable, but if there is an interrupt enable bit in the peripheral that sources the interrupt, use that one to control the interrupt.  If not, then use the bit in the PIEIERx register that corresponds to the interrupt.  If the interrupt happens to be one of the few that does not go through the PIE, then use the IER bit as Johannes showed in his post.  But, I suspect the interrupt does go through the PIE.

    For a PIE interrupt, it is easy to enable/disable it.  Like this:

    PieCtrlRegs.PIEIER1.bit.INTx6 = 0;   // disable the interrupt in the PIE
    memcpy(tmp_buf, data, len);
    PieCtrlRegs.PIEIER1.bit.INTx6 = 1;   // Enable the interrupt in the PIE

    The above example is showing PIE group 1, interrupt 6.  But it could be any interrupt.

    Note that the downside of using the IER bit to disable a PIE interrupt is that it will disable ALL interrupt in the PIE group, not just the one that is of interest.  That why I suggest using the PIEIERx (or peripheral interrupt enable).

    Regards,

    David

  • Thanks for your valuable input, David.

    Regards,

    Gautam

  • David M. Alter said:
    to control the interrupt.  If not, then use the bit in the PIEIERx register that corresponds to the interrupt.  If the interrupt happens to be one of the few that does not go through the PIE, then use the IER bit as Johannes showed in his post.  But, I suspect the interrupt does go through the PIE.

    It is the Timer 2 interrupt (which does not go through the PIE). So, I'll leave it as it is.

    Thank you, David, for your detailed answer.


    Regards,

    Johannes

  • Johannes,

    Timer2 does have a peripheral interrupt enable bit, TIMER2TCR.TIE.  Personally, I would use that bit instead of monkeying with the IER.  Although for non-PIE interrupts it doesn't really matter, in general it is good practice to manage interrupts as far outbound from the core as possible.  That has the smallest chance of any unforseen side-effects in your system.

    - David

  • David,

    thank you for your advice.

    Would in both cases (disabling using TIMER2TCR.TIE or IER) the interrupt be serviced after it had been re-enabled (in case Timer2 reached zero while the interrupt was disabled)?


    Regards, Johannes

  • Johannes,

    Yes, you can disable the interrupt at any point along the logic path and when it is re-enabled any pending interrupt on that path will get taken.  The enable bits do NOT affect the interrupt flag bits.  The flags stay pending.

    - David