Interrupt latency.

[rew]

Hi,

I'm having an issue with interrupts not getting handled "in time" by my firmware. How long would chibios disable interrupts for "critical section" stuff?

Is there a way to debug this that I can find the places where the delay happened?

[Giovanni]

Hi,

If you enable statistics then the debug plugin will report you the longest path in critical sections and in IRQs.

If you have the need to handle very critical interrupts then consider using priorities 0 and 1, but no OS code can be called from in there.

Giovanni

[mikeprotts]

For my time critical sections, I've used IRQ priority zero or one (experimenting a bit). I use the interrupt to set a few global variables, handle a counter and then set global flags that are used in processing at thread level priorities (where time is less critical). I can see from logic analyser that this really does run ahead of everything else.

I started using priority 2, with it being the only interrupt at that priority; it was very fast, but still had a noticeable jitter when looking at microsecond level. I switched to higher priority to remove the jitter as I need timing consistency for this section of code.

Running an STM32F4 or F7 at 168MHz, with priority zero or one, I see a consistent delay of about 750ns from the rise in the trigger to the rise in an output pin I set early in the processing. I currently only have one interrupt that uses this high priority, although I may have cause to have a second, hence my experimentation.

I use the first interrupt (Vector58) as it's non-shared. Other interrupts are ordered by priority. I don't know if DMA priority affects interrupts, but from the consistency I assume not much.

Mike

[Giovanni]

Latency of priority zero should be 12 cycles assuming there is only one source, the kernel never blocks levels 0 and 1.

DMA should not affect much, bus masters are rotated so it would be matter of few cycles.

Note that from fast interrupts you can "delegate" calls to the kernel by using PENDSV.

Giovanni

[mikeprotts]

12 cycles at 168MHz should be a lot less than the time I'm seeing, but there is some of my own processing. I'll have a check on this.

The use of PENDSV might help with the jitter I see with SPI ADC (it's a single sample each transfer), so thanks for the hint. That's the interrupt I am thinking of running at priority 1, with a thread (or maybe lower level software interrupt) running the SPI Exchange. I'd rather use a circular buffer and leave it to asynchronous calls, but that's probably something I'll look at for a future release.

Mike

[rew]

OK!

I already have put the critical interrupts at level 1.

So critical sections in the kernel block level 2 and level 3 interrupts but not 0 and 1? That would mean that my interrupt should always happen and not be blocked by anything, right?

In both interrupts, I set a GPIO pin as one of the first things, and then reset it as one of the last things. Both interrupts just "do their thing" and don't need any OS calls (anymore).

But then: Why do I still see quite some jitter on the interrupt service time?

I'm still using the exti driver, which has some unnecessary stuff, for example, the distribution to the different functions that could be on the different channels.

#define STM32_EXT_EXTI4_15_IRQ_PRIORITY 1

This doesn't happen all that often. My current test does this every 200ms or so.

About 500 times per second TIM3 compare happens. TIM3 is in encoder mode, so there is an external encoder that causes the timer to increment.
I use a logic analyser sampling at 12MHz to see what happens.
I see the timing-debug PAD change in the 33rd or 34th sample after the encoder signal change. Of 93277 samples, 92394, 99%. Good. But 559 times the signal change happens between the 40th and 90th sample after the change in the encoder signal. Now if say none happened after 5 microseconds, or 6 samples after the signal change, I'd be happy with "up to 3.2 microseconds of delay that MAY happen depending on something". But the tail is falling off quite slowly. With a different analysis I've found ONE example where the interrupt happened with the encoder a full step further than the intended trigger point.

[rew]

If you enable statistics then the debug plugin will report you the longest path in critical sections and in IRQs.

I'm thinking this refers to plugins for chibistudio. I'm a Linux user and IIRC you've said that chibistudio is available for Linux too.

When I search for "chibistudio download", google points me at a non-existant page at sourceforge as the first two hits. The third link has a direct download for the windows version, and I presume a link to get all the other versions. getchibistudio.chibiforge.org, but that just links to the same page with just the windows version. I give up.

[Giovanni]

I would have tried "download" from the homepage, that usually works:

http://chibios.org/dokuwiki/doku.php?id ... oads:start

I will fix that download.chibios.org

Note that you cannot use HAL service routines at priorities 0 and 1, the ISRs use the prologue/epilogue macros that must not be used for fast interrupts, you need your own ISRs.

Giovanni

[mikeprotts]

STM32_EXT_EXTI4_15_IRQ_PRIORITY

That's a shared interrupt, so may be in use for something else. As you have more than one interrupt in use at the same level, you will not have any control over the order they run. Are you able to use non shared interrupts, and can you make the most critical one run at priority zero?

Mike

[rew]

Note that you cannot use HAL service routines at priorities 0 and 1, the ISRs use the prologue/epilogue macros that must not be used for fast interrupts, you need your own ISRs.

Wait!

I have:

Code: Select all

OSAL_IRQ_HANDLER(DMATIM_VECTOR)
{
  OSAL_IRQ_PROLOGUE();

  SET_DBG1 ();

  DMATIM->SR = 0;
  numtimirqs++; // for debugging: count how many times this happens.
  // my code (two lines)
  CLR_DBG1 ();
  OSAL_IRQ_EPILOGUE();
}

I'm not supposed to do the OSAL_IRQ_PROLOGUE /EPILOGUE thing? Something else??

The other "high priority" interrupt that I have is the EXTI one. I just changed the define for the IRQ priority to "1".

Code: Select all

#define STM32_EXT_EXTI4_15_IRQ_PRIORITY     1


Those are documented as:

Code: Select all

 * IRQ priorities:
 * 3...0       Lowest...Highest.


so I was thinking that I can use levels 1 and 0 if I need a priority gradient between interrupts from different sources. The simplest case might be that if say UART is running at 250kBaud, you have 40 microseconds between bytes. Another datastream may have a shorter time to "hardware overrrun", so you'd increase the priority (lower number) of that over the uart interrupt.

I have seen a scheduled timer interrupt get interrupted with these higher priority ones, through my single-GPIO deubugging trace.

My "report" thread has now stopped working "overnight" on two consecutive nights. The first time I tried setting breakpoints in the code in the thread but none were hit anymore.

The second time I got the impression that stuff was still being called, just no output on the VCP.

@mike: I don't see what else EXTI4_15 is being used for. I'm not using any other channel on that EXTI interrupt, there is no other source for that NVIC interrupt listed in the datasheet (STM32F072, RM0091).

My two high prio interrupts should not happen at the same time. Think of it as a clock. When the hand points at 12, I get the EXTI interrupt. Then the other interrupt is scheduled to happen at various other positions around the clock. I keep the area around "12" clear from the other stuff.