• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 84 subscribers
  • Views 341 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.

TMS320F28035: Clear pending timer interrupt

Román Comelli
Intellectual 545 points
Part Number: TMS320F28035


Hi,

I am trying to implement some time services that involve using timer 1 with, potentially, any counter value. I mean that the counter register could be set to 1, 2, 3, etc. Ideally, I would need that when the counter reaches zero, the period is not reloaded but unfortunately I did not find a way to do it, and I think it is not possible. Then, it could happen (more likely when the counter register was set to a small value) that when the interrupt is serviced, another (same) interrupt is triggered. Right now, my approach to solve this problem is to stop the counter and clear any pending interrupt from timer 1, immediately after the ISR execution started:

static __interrupt void HandleTimerEventIsr(void) {
  CpuTimer1Regs.TCR.bit.TSS = 1;
  IFR &= 0xEFFF;
  ...
}

According to what I have read ("TMS320F2803x Piccolo Technical Reference Manual", "TMS320C28x Optimizing C/C++ Compiler User's Guide" and "TMS320C28x CPU and Instruction Set Reference Guide", apart from other questions in the forum), there should not be any problem with this approach. Anyway, I wanted to be sure that:

-No interrupt could be lost (I do not think so because the assembly generated instruction is an atomic AND).

-No other timer 1 interrupt could happen after this (for example, in a worst case scenario with the counter register set to 1, I am not sure if some internal latency between the counter reaching 0 and the interrupt being triggered could case that clearing this interrupt in IFR immediately after stopping the timer is not enough to avoid another same interrupt).

Thank you in advance!

  • 0
    TI__Expert 8251 points

    Hi,

    These registers (CpuTimer1Regs.TCR.bit.TSS) are EALLOW protected registers. Please make sure you set EALLOW before writing to these registers.

    Usually compiler read the register value and write back the updated value in the TCR register. So we need to mask the TIF bit before writing back.

    In the CPU Timer control register, a write of 1 to the TIF register clears the flag, if it was already set.

    Thanks 

    Aswin

  • 0 in reply to Aswin P
    Intellectual 545 points

    Hi,

    I think timer registers are not EALLOW protected. Anyway, sorry but you are not answering what I have asked. I have done some experiments related to my second question so now I know that I have to wait some clocks between stopping the timer and clearing the corresponding interrupt flag. On the other side, I would still like to receive a clear response to my first question.

  • 0 in reply to Román Comelli
    TI__Mastermind 25360 points

    Hi Roman,

    We are working on assigning your question to someone on our team. Please await a response soon.

    Best Regards,

    Marlyn

  • 0
    TI__Mastermind 25360 points

    Hi Roman,

    Since you can never be sure of the timer value at the time the ISR is entered, the code you wrote can have some race conditions.

    You have to make sure that the IFR is cleared after the timer has stopped. The IFR clearing happens inside the CPU, while the TSS bit in the timer get set by a memory write on the peripheral which can take many cycles.

    static __interrupt void HandleTimerEventIsr(void) {

      CpuTimer1Regs.TCR.bit.TSS = 1;

    Have at-least 8 cycle distance here

      IFR &= 0xEFFF;

      ...

    }

    The delay itself can be realized in multiple ways.

    Example:

    CpuTimer1Regs.TCR.bit.TSS = 1;
EALLOW
EDIS
IFR &= 0xEFFF;

     

    A different point to be aware of :

    Please note that the above ISR code will take effect only after the CPU gets a chance to service the timer interrupt. Since it is a free running timer, if the user code (For example a higher priority interrupt) prevents the timer interrupt from being serviced for a long time, it is possible that the timer wraps around more than once and fires the interrupt more than once even before the timer ISR is executed even once.

    Best Regards,

    Marlyn

  • 0 in reply to Marlyn Rosales Castaneda20
    Intellectual 545 points

    Ok, thank you for the answer. Those 8 cycles are due to the 8 stages of the pipeline, right?

    Regarding the different point to be aware of, I have tried that situation (I have unsuccessfully look for information that suggests this problem on the TRM) and it seems that even though the timer fires more than one interrupt, if disabling the timer and clearing the pending interrupts is correctly done (waiting that time you mentioned), no spare interrupts are serviced. Is there something I am missing?

    And lastly, just to be sure (the first question I made), no interrupt is lost by clearing them with IFR &= 0xEFFF, right?

    Regards,

    Román

  • 0 in reply to Román Comelli
    TI__Mastermind 25360 points

    Hi Roman,

    Román Comelli said:
    Those 8 cycles are due to the 8 stages of the pipeline, right?

    Yes

    Román Comelli said:
    Regarding the different point to be aware of, I have tried that situation (I have unsuccessfully look for information that suggests this problem on the TRM) and it seems that even though the timer fires more than one interrupt, if disabling the timer and clearing the pending interrupts is correctly done (waiting that time you mentioned), no spare interrupts are serviced. Is there something I am missing?

    Please review TRM section 1.6.3.1 'Procedure for Handling Multiplexed Interrupts'

    Román Comelli said:
    And lastly, just to be sure (the first question I made), no interrupt is lost by clearing them with IFR &= 0xEFFF, right?

    Correct

    Best Regards,

    Marlyn