Fast Interrupt Jitter

[fractal]

Hi everyone,

we have a problem with fast interrupts which we have not been able to solve for a while. It may not be directly related to chibios, but I still think this is the best place to ask.

We are using the internal comparator (COMP1) on the F3-series to generate a fast interrupt. These interrupts are generated via the exti-system (line 21), everything is configured accordingly, without using the OS functions. The vector was added to vectors.c and triggers reliably, the routine right now does almost nothing except clear interrupt and flag, check for the comp state and switch a GPIO-pin.

The problem is the jitter we are seeing, the time between an edge on the external comparator signal and the GPIO edge varies between 300 and 1050 ns, at 72MHz this is 20-75 cycles. For our application a constant value as low as possible is important (300ns would be great), so we tried everything but we can not get rid of the jitter. I was expecting the jitter to be much lower for a fast interrupt without OS interaction. Does anyone have any experience whether this amount of jitter is normal? Any idea how to reduce it?

We would be gerateful for any help. The code of configuration and ISR routine is below.

Best regards,
Thomas

Configuration:

Code: Select all

  EXTI->IMR |= EXTI_IMR_MR21; //enable EXTI for comparator output
  EXTI->RTSR |= EXTI_RTSR_TR21; //Detect rising edge at comparator output
  EXTI->FTSR |= EXTI_FTSR_TR21; //Detect falling edge at comparator output
  nvicEnableVector(COMP1_2_3_IRQn,0); // enable interrupt with high priority

Interrupt routine:

Code: Select all

CH_FAST_IRQ_HANDLER(Vector140)
{
  nvicClearPending(COMP1_2_3_IRQn);
  EXTI->PR &= ~EXTI_PR_PR21; // clear flag of comp interrupt
  if ((COMP->CSR & COMP1_CSR_COMP1OUT))
  {
    palSetPad(GPIOA, GPIOA_MCU_OUT); //Turn gate off
  }
  else
  {
    palClearPad(GPIOA, GPIOA_MCU_OUT); //Turn gate on
  }
}

[Giovanni]

Hi,

Jitter should not be that high, the only thing I can imagine is that there is a latency caused by wait states in the flash controller but 75 cycles are way too much. This could be avoided by placing the ISR in RAM.

About "nvicClearPending(COMP1_2_3_IRQn);", is this really required? NVIC interrupts are cleared automatically usually.

Do you have other interrupts at that priority level? that could explain it. Also verify if it could be a measurement issue, you are triggering on an analog signal if I understood it right.

Giovanni

[fractal]

Hi Giovanni,

thank you for your input.

You are right, the ClearPending was just in there for debugging, it is not necessary. We are measuring the delay with a decent oscilloscope, I don't think its an analog issue.
Relocating the ISR to ram is a good idea, but from the available documentation (ARM, ST, chibios, various forum entries with unsolved issues and conflicting advice) it is very hard to figure out how to move it. If we just tell the compiler to move it to ram0 or ram4 the dump shows the correct address, but we get an unhandled exception when the ISR is called, I guess we may have to move the table as well for it to work? Could you point us to a good resource on how to move to ram and possibly also move the vector table to ram? That would save a lot of time and frustration

Best regards,
Thomas

[Giovanni]

Hi,

Moving the table to RAM is not so immediate, you need to copy it at startup and the ChibiOS code does not do that. It requires significant changes to the ld files too.

Anyway, I doubt it is the full cause of your jitter, at most it would give you few extra cycles.

Giovanni

[rew]

As for debugging where this comes from:
Try it without the comparator: use a direct digital IO. If the jitter still happens it's in the exti to IRQ routine part, if it goes away it's in the analog part. (consider two experiments: One where you use exti, and one where you use one of the interrupt pins. )

You could argue: But it can't be .... (analog or digital). You're right. So we're left with observations that cannot be caused by either the digital part or the analog part. Still we're seeing the jitter. Better find out which of the "can't be xxxx" is wrong....

IF the system blocks interrupts (I think that the idea of fast interrupts is that they should not be blocked, right?) then a normal interrupt (i.e. not a fast one) would show similar jitter.

On AVR the latency to interrupt execution is 1 or two clock cycles. This depends on the instruction being executed when the interrupt reaches the interrupt controller. Storing the return address from the stack may help in finding such long instructions. But again, this seems unlikely as there should not be any instruction halting the system for 75 clocks.... ... on the other hand... If you're writing to flash, that would stall the CPU before its next instruction access... But again not compatible with the observations: 50 microseconds typical programming time.