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.

Detecting CPU timer interrupt overruns in F28335

Is there a way to detect CPU timer interrupt overruns, i.e., if the interrupt service routine is taking to long to complete so timer interrupts are lost? I tried to use a simple overrun flag but it looks like that interrupt service routines are not called unless the previous one is completed:

interrupt void cpu_timer0_isr(void)
{
	static int overrunflag = 0;

	DINT;
	if (overrunflag) // Detect overruns
		overruns++; 
	overrunflag = 1; // Set overrun flag
	EINT;
	PieCtrlRegs.PIEACK.all = PIEACK_GROUP1; // Acknowledge interrupt

   CpuTimer0.InterruptCount++; // Do something

   DELAY_US(delaytime); // Waste time...

   overrunflag = 0; // Clear overrun flag
}

  • Hi Andrea,

    Your observation is true! Try overruning to an extent where the ISR takes more time than CPU_Timer itself.

    Regards,
    Gautam
  • Yes, interrupts are missed and the overruns variable is never incremented. Any solutions?
  • Andrea,

    Your ISR will not be interrupted by another timer 0 interrupt. This is because bit 0 in the IER register is automatically cleared by the CPU when it takes the interrupt. That bit is restored only when the IRET instruction pops the stored IER value off the stack when the interrupt terminates.

    Timers 1 and 2 do not go through the PIE, so you could make their ISRs nestable simply by manipulating IER just before the EINT instruction.
    However, since CPU timer 0 passes through the PIE there are some special requirements to be observed. These are set out in the "System Control and Interrupts User's Guide" for the F28335. The TI literature reference is "sprufb0d" and the information is in chapter 8.3.

    Now, to detect whether a further CPU timer interrupt has arrived before the end of your ISR you can clear the TIF bit in the TCR register at the beginning of the ISR, then read it again at the end. However this won't trap the boundary case when TIF is set just before the ISR terminates. For that you're also going to need to read the TIM register at the end of the interrupt and compare it with some small threshold (recall, CPU timers are down-counting) to be sure you have enough time to get through the context save.

    Regards,

    Richard