TMS320C5515 timer 1 & 2 conflicts/misses

I've added some o-scope captures to illustrate the problem.

In the attached images, the top pulses represent a GPIO pin being toggled in timer 1. The bottom pulses represent a GPIO pin being toggled in timer 0.

Timer 0 is setup to fire every 71.6 uS. Timer 1 is setup to fire every 60.5uS.

"Expected Behavior.jpg" illustrates a scenario where timer 0 (bottom waveform) can be seen executing every 71.6uS. It can be seen that timer 1 executes and blocks (a little longer than the 1 uS I listed in the comments of the first post), causing a delay in the 3rd firing of timer 0, as expected. Based on the way the ISR is written, this shows that the timer 1 routine executed, the ISR exited, and was immediately entered again to service the pending timer0 interrupt.

"Missed Interrupt.jpg" illustrates a scenario where both timer 0 (bottom waveform) and timer 1 are both executing. It can be seen that the 4th pulse of timer 0 is missing. If one looks at the cursors, it can be seen that the missed firing of timer 0 occurred at the exact same time when timer 1 begins
execution. I would expect a similar result as shown in "expected behavoir.jpg" where timer 1 would first execute, the ISR would exit and be re-entered,and then the timer 0 code would be executed.

I've also made observations where timer 1 is missed when the timer 0 interrupt fires off at roughly the same time.

It appears the ISR is not being re-entered when timers 0 & 1 expire simultaneously.

I'm hoping I'm doing something wrong with my ISR setup, not some low level time bug within the DSP. I see the TINT bit of IFR0 is self clearing when the ISR is entered. I would think this bit needs to set again if two timer interrupts go off at the same time in order for the ISR to be re-entered.

Expected Behavior:

Missed Interrupt:

Hello Adam,

  Looks like you are clearing both the interrupts in your ISR.

The ISR can choose to service both timer interrupts or only one-at-a-time. If the  ISR services only one of them, then it should clear only one of the TIAFR flags and upon exiting the ISR, the CPU will immediately be interrupted again to service the second timer flag.

Hope this helps.

Regards

 Vasanth

I'm afraid I don't understand Vasanth. I'm only clearing the respective TIAFR bit only after meeting the condition in each IF statement. Therefore, if I enter this ISR and both TIM0 and TIM1 flags are set in the TIAFR register upon entering, then they both are serviced because of the way the if statements are setup. If only timer0 bit is set, then only timer0 is cleared in the TIAFR.

The clearing of the respective TIAFR bits only occur as needed. If I understand your response correctly, your stating that that I'm clearing both TIAFR bits every time this ISR is called.

What is the register_value you read before you service the respective Timer ISR.

Also I would like yo to check the INTM bit status : Below is the information in INTM :

Before executing an interrupt service routine (ISR) triggered by an INTR #5 instruction, by the RESET instruction, or by a hardware interrupt source, the CPU automatically sets the INTM bit to globally disable the maskable interrupts. The ISR can re-enable the maskable interrupts by clearing the INTM bit.

A return-from-interrupt instruction restores the INTM bit from the data stack

More information on the INTM can be found in the Link swpu073e

Please confirm on the above.

Regards

 Vasanth

The first step in the execution of the SIR is to read the Timer Interrupt Aggregation Flag Register (TIAFR, 0x1C14) and check bits 0 and 1 to determine source of the timer interrupt .

In regards to your second question, I set a breakpoint at the first line of the timer ISR and observed the INTM bit set to one. This confirms SWPU073. Upon leaving the ISR and returning execution to the main loop, I observed the INTM bit restored to 0.

However, I was able to fix my problem by changing the way I write a 1 to the TIAFR to clear the respective flag.

The previous code (as shown above) used a logical OR to set the bit (TIAFR |= 0x01). Upon looking into the CSL code, I observed the value use to set the respective bit was directly written into the register (TIAFR = 0x01;). It's somewhat counter intuitive to me to overwrite a register value instead of ORing in the bit I want to set, but I understand I can get away with it since this register is not effected with writes of zero to any bit.

I guess there was some kind of timing issue going on since the OR line of code causes a read and write of the memory location while the write is just that, a direct write. 

Any thoughts why I can't get away with the OR to set that bit?

Indeed it does. The OR condition works 99% of the time, it doesn't work in that small window where the DSP sets the bit between the ISR firing and the time I perform the OR.

Thank you again for your diligence in following through with this question!