• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 592 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.

CPU Timer1 not always triggering, INTACK issue?

Edward Averill
Genius 3100 points

I'm prettysure I'm not propperly acknolwedging the CPU TIMER1 interrupt.

I set it up:

  

   // 80MHz CPU Freq, 100 microsecond Period (in uSeconds), 10kHz interrupt
   ConfigCpuTimer(&CpuTimer1, 80, 100);
   CpuTimer1Regs.TCR.all = 0x4000;
   // Enable all interrupts globally
   IER |= M_INT8 | M_INT1 | M_INT3 | M_INT13;


..then at the end of the ISR I say:

   PieCtrlRegs.PIEACK.all = M_INT13;

Oddly, in the cpy timer example I see in the Resource Explorer I don't see any ACK:

__interrupt void cpu_timer1_isr(void)
{
   CpuTimer1.InterruptCount++;
   // The CPU acknowledges the interrupt.
   EDIS;
}

..which is confusing.  I see BIT 12 (Timer 1) set in the IER, and in the IFR, when my code executes.  I get the feeling I need to manually clear the IFR buit for Timer1 but none of my examples do that.

Does anyone have any idea of what could be happening here?  There's no codfe path around the PIE ACK, so that's not an issue, yet it appears that eventually soem flag stops being cleared and that's it for my ISR.

  • 0
    TI__Guru 61235 points

    Edward,

    You don't say which device you are using, but I get the feeling it is F2806x judging by your 80 MHz operation.  The Timer1 interrupt does not go through the PIE.  Only the Timer0 interrupt goes through the PIE; Timer1 and Timer2 interrupts are directly connected to the CPU core.  See the interrupt section of the device datasheet (e.g., SPRS698D, Figure 5-10 for the F2806x).  That is why you don't see the PIE being 'ACKd in the TI example code.

    Regards,

    David

  • 0
    Genius 3100 points

    This was a fun one to chase down, but I got it!

    The original engineer on the project (long gone) had set everything up to operate in ISRs, with a small main task loop.  The only ISR every tested for functionality was CPU Timer 0.  I refactored the code to use a tight loop instead of 4 cut-and-pasted cipies of identical code (long story), which made the code very tight and fast.  This exposed a bug - the original engineer had set CPU Timer 0 up to interrupt every 100 MICROSECONDS, locking out everything else on the micro as the ISR was re-entered immediately on exit.

    Turning the ISR down to once every 10msec (this is polling a vehicle sensor) suddenly made everything else work.  Amazing (said with some sarcasm).  Never a dull day...