TMS320F28069 CPU stops INTs after 1-20 entries

Edward Averill

Ok, this one is a stumper. I have CPU Timer0 driving a sensor polling loop, but after just a few entries it flat out stops interrupting. I also have a Timer1 loop and *IT* works just fine.

Setup code:

   // Enable TIMER 0 interrupt in PIE: Group 1
   PieCtrlRegs.PIEIER1.all = M_INT7;
   // Enable EPWM1 interrupt in PIE: Group 3 interrupt 1
   PieCtrlRegs.PIEIER3.all = M_INT1;

   // Enable all interrupts globally
   IER |= M_INT8 | M_INT1 | M_INT3 | M_INT13 | M_INT7;

.. the ISR:

__interrupt void cpu_timer0_isr(void)
{
	CpuTimer0.InterruptCount++;

//.. proprietary stuff..

   // Acknowledge this interrupt to receive more interrupts from group 1

   PieCtrlRegs.PIEACK.all = PIEACK_GROUP1;

}

I see CpuTimer0.InterruptCount reach between 10-30 before it quits counting. I try putting a breakpoint in and, yes, it's never hit.

This is an inherited project and Im not familiar with this MCU, but if it works once or twice I'd think it'd work forever.

All assistance, manual pages, code snippets, GREATLY appreciated.

Ed Averill

over 12 years ago

0 David M. Alter over 12 years ago

TI__Guru 61235 points

Edward,

I can offer you some advice on debugging this.

If an interrupt is flagged and enabled, it will get taken. So in your case, either the interrupt flag chain is not getting set (there are multiple flags involved here), or the interrupt is not enabled (and similarly, there are multiple interrupt bits here).

First, when the problem happens, HALT the processor and check to see if Timer 0 is still counting. Look at the Timer count registers (TIMER0TIM and TIMER0TIMH) in the CCS register view. Note its value. Then RUN and HALT again. Did it change? If it changed, the counter is still running. If it didn't, the timer is halted and you need to look at the timer registers to see why it is disabled (and then figure out what disabled it).

Assuming the timer is still running, follow the interrupt flag chain from the timer to the CPU. It the TIMER0TCR.TIF bit set? Is it enabled with the TIMER0TCR.TIE bit? If so, go to the PIE, and check the corresponding PIEIFRx flag and PIEIERx bits. Are they set? If so, go to the CPU IFR and IER regs (what I mean here is look at them in the debugger window). Is the PIE group flag set and enabled for the PIE group that the timer0 is on? Final check point is the INTM bit in the ST1 register (the global interrupt mask). Is INTM=0 (which means ints are enabled)?

Again, if the interrupt flags are all set and the interrupt enable bits are all enabled, the interrupt HAS TO BE TAKEN. No way around this. You just need to find where the bottleneck spot is in the chain. A final thought that the bottleneck could be at the PIE. If another PIE interrupt on the same GROUP as the Timer0 were taken and the ISR for that other interrupt failed to 'ACK the PIE (or if TImer0 failed to 'ACK the PIE), you won't get another interrupt on that PIE group. Look in the device datasheet for whatever device you're using and find out what other interrupts are on the same PIE group as the Timer0. If you are using any of those other interrupts, check their ISRs to make sure the PIE is being properly acknowledged (you're looking for a write to the PIEACK register). Also check the Timer0 ISR for the same.

Regards,

David

0 Edward Averill over 12 years ago in reply to David M. Alter

Genius 3100 points

Ypu. sir saved my sanity! I owe you a soda/beer/iced tea of your choice!

After chasing the flaags (all good) interrupt enables (all good), and seeing the darn INT flags set, I started to wonder if there were an early exit buried in the code somewhere inobvious.

And lo, there it was! Under specific timings, the ISR would exit withuout acknowledging the INT and past that point, of course, it was toast.

It was a one-lione fix oncew I debugged it and it was your help that made it possible.

Have a great rest of the week!

Ed Averill

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28069 CPU stops INTs after 1-20 entries