interrupt latency on 28035

400ns is 24 cycles. That's high in variability, what is the overall delay? Are you clearing the interrupt or getting nested?

See this

http://processors.wiki.ti.com/index.php/Interrupt_FAQ_for_C2000#ISR_Latency

The interrupt is cleared before exiting. The overall delay is between 200-600 ns.

Is your interrupt set to go on Tmr = Zero, Tmr = Period or Tmr = Compare Value?

And how exactly are you measuring the 200ns-600ns delay?  Is it between the PWM toggling on TMR=zero and GPIO6 toggling?

Tim

The interrupt is set to go at Tmr=Compare value. The measurement is done between PWM3  toggling at  Tmr=compare and GPIO6 toggling. The delay doesn't bother me as much as the fact that it is variable.

Probably one thing to try is to set the interrupt to Tmr = zero (as a test) and then measure the delay between that and the GPIO6 toggle.  Does this produce the same results?

I noticed that if I cancel all of my statements in my C infinite loop (there were a couple of if-else statements and a few counters), the variation in latency becomes minimal (in the order of 16-30 ns). So it seems that this is the problem. So here are my two new questions:

- which statements are more likely to create such problems (basically they will not get interrupted and they take longer to execute

- even more important to me, the time-compare triggers an A/D SOC which needs to be precisely at the same time every time. Is this going to be affected in the same manner (delayed) or not? I assume it is hardware based, so it should not have a reason to wait for the execution of certain statements in C. I do not have a good way of testing this.

amuliu proca said:

- which statements are more likely to create such problems (basically they will not get interrupted and they take longer to execute

You would need to provide some examples in order to help with understanding the impact.

amuliu proca said:

- even more important to me, the time-compare triggers an A/D SOC which needs to be precisely at the same time every time. Is this going to be affected in the same manner (delayed) or not? I assume it is hardware based, so it should not have a reason to wait for the execution of certain statements in C. I do not have a good way of testing this.

If you have the A/D start of conversion (SOC) triggered from the timer compare, this is implemented in hardware and should not be affected by any variability induced with code executing on the CPU (provided that the code doesn't disable the SOC or something to that effect).

Is your emulator connected?  You may want to try the experiment running from Flash and not connected to your computer.

(But make sure your ISR function is copied and ran from RAM).

I believe the emulator steals cycles from the DSP using emulator interrupts.  If I'm wrong, please correct me.

As others have said, without seeing the code it would be hard to say which instructions are causing the latency.  Are you running a RTOS (such as DSP/BIOS or something else)? or using critical sections of code?  Those two things would be possible causes of variable latency.

Tim