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 180mhzThis 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

[Tesla DeLorean]

Posted on December 14, 2016 at 17:43

If the ART is not enabled you're going to get raw FLASH performance, when it reads the vector table, and pulls the instructions. Figure 35-40ns a piece. All the code and vector table should reside in TCM RAM for optimum speed.

The M7 likely has a deeper pipeline, and has to stack the current state. As Jan points out this isn't going to be couple of cycles.

This doesn't cover the M7

https://www.community.arm.com/processors/b/documents/posts/a-beginner-s-guide-on-interrupt-latency---and-interrupt-latency-of-the-arm-cortex--m-processors

 

Wiki says it is still 12 cycles. Avoid slow external memory for stacks

https://en.wikipedia.org/wiki/ARM_Cortex-M&sharpCortex-M7

 

[waclawek.jan]

Posted on December 14, 2016 at 17:53

I am a beginer ...

Interrupt latency in 32-bit SoC as the STM32 are is a convoluted issue. It's unlikely you will solve this unless you understand all 4 points I gave above. To quote Lenin, the only way is to learn, learn, learn... Clive gave you good pointers to start with.

Also, start with cutting down the time in the F4 first - as soon as you reach the 12-cycle latency (plus software overhead, again cut down to the bone - you should be able to get to roughly half of what you have now) you are on the right way.

JW

[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.