Interupt responstime issue stm32f429 vs stm32f767

[Hans T]

Posted on December 14, 2016 at 14:36

hello,

I'am use for a project the stm32f429. The interrupt handler must react so soon as possible.

The stm32f429 interrupt responstime is 218ns.

It's  fast but not fast enough.

I decided to make a new design with the stm32f767 running at 216 mhz.

With the same configuration as the stm32f429 running at 180mhz

This configruation is generated with STM32CubeMX / KEIL vision MDK-ARM V5

However the interrupt response time is much longer, it is 376ns !!

Well is the processing of instructions faster.

What is the reason that the stm32f767 has a longer response time compared to the stm32f429 ??

#interupt-stm32f767-vs-stm32f429-responstime

[waclawek.jan]

Posted on December 14, 2016 at 14:58

Instead of trying to explain the many sources of interrupt latency (and there are many of them, most of them hard to control or avoid) and its jitter, and difference between mcu models and other particularities of design, I suggest to give up the idea of having latencies below dozens of machine cycles in any 32-bitter up front.

For controlled latencies below 1us, use hardware. There's plenty of hardware in these chips. Tell us more details of your requirements to receive more help.

[Hans T]

Posted on December 14, 2016 at 15:19

Hello waclawek.jan thanks for your reply

I am aware that there is faster hardware. Often, there is provided a FPGA with embedded ARM core.

I want to find the limit. The STM comes at the place of a RAM chip, any read / write comes within an interrupt in the STM

it works good with the stm32f4 <250ns, the more time I have on the more opportunities I get to influence the RAM data.

[waclawek.jan]

Posted on December 14, 2016 at 15:42

Some of the possible sources of latency:

- stack in slow memory

- execution from slow memory

- complete vs. lazy FP stacking

Perceived latency (e.g. delay between interrupt edge on input pin and edge on an output pin manipulated at the beginning of ISR) is added up from the hardware latency and any software the compiler might insert between ISR entry and the instruction which performs the pin manipulation. Study the disassembly.

JW

[Lawliet KG]

Posted on December 14, 2016 at 16:04

Hi Hans,

Are you measuring the interrupt response time on the first iteration? Could you give as the response times for the second and the third iterations?

If you will use the STM32F7, I advise you to use the ITCM RAM memory. It is reserved for the CPU Execution/Instruction

useful for critical real-time routines.By the way, what is the the response time value needed for your application ?

Note: 

 The 

stm32f429 and 

stm32f767 devices do not share the same bus-matrix architecture; So, using the same configuration (with the same clock value) does not mean that you will get the same interrupt time response.

Regards,

Lawliet.

[Hans T]

Posted on December 14, 2016 at 16:49

Hello Lawliet

The same configuration I mean the test, see scoop image.

Yellow channel is the chip select connected to the PC0 of the STM

The PCO is configured as ''Interrupt Mode Ecternal widh trigger Falling edge detection''

Purple channel is the PG13 standard GPIO output (High speed) GPIOG-> = BSRR GPIO_PIN_13.;

Very simlpe test.

The question remains, What is the reason the stm32f767 That Has A higher response time Compared to the stm32f429 ??

and has the stm32h7 same response time (next year)

[waclawek.jan]

Posted on December 14, 2016 at 16:56

I gave you several possible reasons above. It's up to you to sort out.

Lawliet gave you

a question

a couple of questions, please answer them (one of them is aimed at the slow memory to execute from, accelerated by cache).

JW

[Seb]

Posted on December 14, 2016 at 18:04

An MCU and an FPGA have different merits... which was commented already.

Assuming this is highest priority level interrupt, and someone would like to reduce the latency, here would be the things to look at:

1. Make the interrupt vectors in RAM

2. Put the interrupt routine in RAM or in CCM memory on F4 (no stolen cycles by DMA)

Let us know how much of a difference this makes.

[Hans T]

Posted on December 14, 2016 at 18:49

Thanks all,  interested.

I'm going test tomorrow.

It's new for me..study study...

[re.wolff9]

Posted on December 15, 2016 at 11:51

A CPU running with 'about 5ns clock cylce' would at first glance not need a 200-300 ns interrupt entry time. However, with modern processors, memory bandwidth and latency is an important factor. 

When an interrupt happens, there are two important things that need to happen. First there is the saving of state, to allow the program to continue where it left off after the interrupt, and secondly the fetching of the interrupt vector and instructions for the interrupt routine. 

Saving the context is something that takes dozens of cycles, as lots of registers need to be saved. 

To solve this.. some processors have a 'fast interrupt' that uses a bank of special purpose registers. Simply use the other bank of registers and no state saving needs to happen. Also the vector can be preloaded into the PC of the banked register set saving that fetch-from-flash too. 

I thought I saw this principle explained for STM32Fxxx CPUs in one of the manuals. I tried searching the STM32F429 manual for terms like FIQ, 'fast interrupt' and 'fast irq' but nothing shows up. Maybe this feature is not available. 

That said... 200ns seems like a long time. If you set-and-then-reset the GPIO in the interrupt, how long does the pulse become? (I'm suspecting you may be using an inefficient function call to toggle the GPIO, causing a chunk of the latency). 

[Hans T]

Posted on December 15, 2016 at 16:02

200ns

Seems

like a

long time

,

but

don't

shy

..

the

IRQHandler

is

592ns

!!

/**

* @brief This function handles EXTI line0 interrupt.

  @brief Interrupt SLTSL RD/CS1  4000-8000

*/

void EXTI0_IRQHandler(void)

{ 

 GPIOD->BSRR = TestP2;

 

 HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0);

 

 GPIOD->BSRR = TestP2<<16;

 

}

Yellow       = interrupt  falling edge  pin pc0

D2            = GPIOD TestP2

[Seb]

Posted on December 23, 2016 at 12:02

Besides the Flash to RAM to boost, if looking at the interrupt duration, then try this:

void EXTI0_IRQHandler(void)

{ 

 GPIOD->BSRR = TestP2;

EXTI->PR1 |= (1<<0); // clear the pending flag

NVIC_ReleasePendingIRQ(EXTI0_IRQn);

// HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0);

 GPIOD->BSRR = TestP2<<16;

}

And let us know if it is the same...

Having the ISR executing in RAM and interrupt vectors in RAM would also help.