• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 82 subscribers
  • Views 1299 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Xint latency

Michael_V
Prodigy 250 points
Other Parts Discussed in Thread: CONTROLSUITE

Hi.

I'm using external interrupts in my project.

My code essentially  looks like this:

void Function()
{
  SET_GPIO_TO_1;

  ...
}

interrupt void  XINT2_ISR(void)
{
  // Insert ISR Code here
	Function();

  ...
}

When I look in logic analyzer, I see that the latency between the interrupt event and the rising edge of the GPIO is ~2.7 us. Running at 60 MHz.

Does this mean that it takes more than 100 cycles to execute this simple code?

My Function is located in the ramfuncs section, so it's supposed to be very fast.

Am I missing something here? Is this normal?

Thanks.

  • 0
    Prodigy 250 points
    Update:
    Moved the ISR to RAM. The latency dropped to 700 ns.
  • 0 in reply to Michael_V
    Prodigy 250 points
    But there seems to be a jitter... It takes between 700-1200 ns to respond...
  • 0
    TI__Expert 8950 points
    Michael,

    We have a FAQ on this:

    processors.wiki.ti.com/.../Interrupt_FAQ_for_C2000

    700 nanoseconds is 42 cycles at 60 MHz. 16 of that is the interrupt latency. Another 26 cycles for making a function call, loading register addresses from memory (flash?), writing to a register, and propagating the register write doesn't seem unreasonable. If input qualification is enabled, that could account for the jitter.

    You could also try looking at the disassembly to see exactly which instructions are being executed.
  • 0 in reply to Adam Haun
    Prodigy 250 points

    My function is located in RAM.

    Because the pin is configured as GPIO, I can't use it without input qualification (asynchronously). I've attached a screenshot of the jitter. The trigger is on D0 (the GPIO pin input). It seems that the jitter can be around 1 uS. I'm running on 28035 from internal oscillator (no external crystal).

  • 0 in reply to Michael_V
    TI__Expert 8950 points
    Constants are usually stored in flash. If the function uses any of those, there could still be some flash reads. That couldn't produce 1 us jitter, though.

    Do you have any other interrupts enabled? If the CPU is in an ISR, it won't get the XINT until it returns from the ISR. If you ever disable interrupts in your main code, that could produce the same behavior.
  • 0 in reply to Adam Haun
    Prodigy 250 points

    I moved the GPIO toggling to the ISR.

    interrupt void XINT3_ISR(void)  // External interrupt 3
{
  // Insert ISR Code here
	TIMING_GPIO = 1;
  ...
}
    TIMING_GPIO is defined as 
    #define TIMING_GPIO		GpioDataRegs.GPADAT.bit.GPIO25

    And there is still a jitter...

  • 0 in reply to Michael_V
    TI__Expert 8950 points
    Michael,

    Do you have any other interrupts enabled? The XINT won't be taken until the CPU has returned from any other interrupts.

    Thanks,
  • 0 in reply to Adam Haun
    Prodigy 250 points

    I have the 3 Xint interrupts enabled, but they occur in different (constant and defined) timings with enough time for servicing.

  • 0 in reply to Michael_V
    TI__Guru 57255 points

    Hi Michael,

    If you haven't already, I might recommend trying to run your device's external_interrupt example within controlSUITE. 

    For the F2803x device family, it is at the path below (however, may be different for your device):
    \controlSUITE\device_support\f2803x\v130\DSP2803x_examples_ccsv5\external_interrupt\

    You can then measure the jitter/latency in the example and compare its results with what you are seeing in your code (especially the GPIO00 to GPIO30 portion of the example).


    Thank you,
    Brett

  • 0 in reply to Michael_V
    TI__Expert 8950 points
    In addition to Brett's suggestion, here are some more things you can try if you want us to pursue this further:

    * Use XCLKOUT to verify that you're actually running at 60 MHz.
    * Post the disassembly of your ISR.
    * Post the contents of the PLLCR, PLLSTS, CLKCTL, and FBANKWAIT registers, and the contents of the GPxCTRL and GPxQSELn registers for the IO you're using.
    * Check the code in your main loop to see whether it ever disables interrupts. Also, note that some instructions take up multiple cycles in the CPU pipeline, so that could potentially add several cycles of jitter in some cases.

    If I read it right, your scope capture shows that shorter delays are more common. It could be interesting to get a histogram, but I think the above suggestions are more likely to nail down what's going on.
  • 0 in reply to Adam Haun
    Prodigy 250 points
    Thank you all for your suggestions. Right now I stopped working on this design. I'll check what you said when I'll get back to it.