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.

Is TAR register of Timer A still counting and updating itself when the code in the ISR is executiong?



I am starting timer A in continuous mode with a value in CCR0 =10000.

After the CCR0 interrupt comes and the program code enters into the CCR0 Interrupt service routine .

Is TAR register still counting and updating itself when the code in the ISR is executiong?.

What happens if the code in the ISR routine gets stuck,or takes a long time to execute?

  • In continuous mode the counter goes from 0 to 0xffff forever and never pauses.

    Using CCR0=1000 to get an interrupt at that spot, will always happen.

    What can happed due to other ISR  is having long routines so when you service your TA0.0 ISR a little later than normal
    and if you for example set CCR0+=20, to get a short interval for the next IRQ

    It may already have missed the window, software overhead they call it and is very bad as code will not be executed until next time counter goes completely around 0xffff and could be a second or 64seconds depending on how you clock/divide your TA0.


    If you set new CCR0 in the beginning of ISR, you are less likely to miss the next window if your own timer IRQ takes a little longer than normal
    As the IFG flag was cleared when you entered IRQ and if next window happens while you're doing your longer routine, when you exit it will have a pending IFG right away.

  • So you are saying that timer will go on counting ,whether ISR is serviced quickly or takes a long time to complete.
  • Hi Rahul,

    Yes, the Timer A continues running completely independently of the CPU unless you set MCx = 0 to stop the timer. So TAR will continue incrementing even while in an ISR. You have to be careful of this, especially since the timer will run asynchronously to the CPU itself (particularly if you have it being clocked from something different than MCLK).

    rahul sreedharan said:
    What happens if the code in the ISR routine gets stuck,or takes a long time to execute?

    Then you could miss the next interrupt if you have delayed long enough in the ISR that the timer has timed-out again. You want to absolutely keep your ISRs as short as possible (this is good general coding practice too because ISRs are blocking and other interrupts cannot be serviced while in one). www.ti.com/lit/pdf/slaa294 has some good discussion on setting up an interrupt driven application, particularly in Chapter 2 (there are also some other good threads concerning keeping ISRs short if you search this forum). One way people keep ISRs short sometimes, is to set a software flag or increment a variable inside the ISR, then exit the ISR. In the main loop, be checking for this software flag/variable, and do the rest of your servicing there (function calls, etc). Basically in the ISR only do things that you need to happen immediately or not be interrupted, and then let the rest happen in normal code space so that other interrupts can occur.

    Hope this helps give some useful pointers.

    Regards,

    Katie

**Attention** This is a public forum