cancel
Showing results for 
Search instead for 
Did you mean: 

interrupt call back response time

ulao
Associate III

Using a stm32h7

From what I gather this 1.5 responce tie is normal. Is there a trick or two I can use to speed this up? Can I move the callback location in memory? I'd like to get this much closer to a a few ticks.

0693W00000WKMfnQAH.png

10 REPLIES 10
MM..1
Chief II

maybe better is show code. Normal latency for EXTI is in reference manual .

ulao
Associate III

Code is generate by ioc, it should all be standard. I'm using the HAL

pin config was generated with

  /*Configure GPIO pin : PF14 */
  GPIO_InitStruct.Pin = GPIO_PIN_14;
  GPIO_InitStruct.Mode = GPIO_MODE_IT_FALLING;
  GPIO_InitStruct.Pull = GPIO_PULLUP;
  HAL_GPIO_Init(GPIOF, &GPIO_InitStruct);

call back is just

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
 
Test_Execut_start_GPIOG4; //used for debug trace
Test_Execut_stop_GPIOG4;
 
 
  if (GPIO_Pin == GPIO_PIN_14)
    {
      //do code
    }
}

but from the time the int fires to the code its nearly 1.5us.

KnarfB
Principal III

Several factors will affect the timing. Measure the latency not by a GPIO (which adds latency) but by issuing a SEV instruction and measuring a pulse at any pin configured as EVENTOUT. You may add 2 SEV's, one at the beginning of the native IRQ handler void EXTI15_10_IRQHandler(void) (in stm32h7xx_it.c) and a second one in the HAL callback to measure the HAL overhead. Also check that the IRQ handler is compiled with high optimization level such that the function prolog and epilog code is tiny. Check this in disassembly by setting a breakpoint at the handler. And, yes, flash latency may also be an issue which can be eliminated by moving the handler code to SRAM. Disclaimer: not tested on H7 but smaller chips.

hth

KnarfB

S.Ma
Principal

Are all the EXTI vectors going to be regrouped by hal into a unique callback? If yes, hardly speed optimized....

TDK
Guru

HAL_GPIO_EXTI_Callback is not the direct callback function. The callback is EXTIx_IRQHandler, which calls HAL_EXTI_IRQHandler, which calls HAL_GPIO_EXTI_Callback. 1.5us to get through that code, plus about 12 ticks for the IRQ itself to fire seems about right.

If you feel a post has answered your question, please click "Accept as Solution".
ulao
Associate III

thx guys this is exactly what I was looking for

void EXTI15_10_IRQHandler(void)

{

 /* USER CODE BEGIN EXTI15_10_IRQn 0 */

 /* USER CODE END EXTI15_10_IRQn 0 */

 HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_14);

 /* USER CODE BEGIN EXTI15_10_IRQn 1 */

 /* USER CODE END EXTI15_10_IRQn 1 */

}

ulao
Associate III

its saved me a whopping 126 ns

void EXTI15_10_IRQHandler(void)
{
Test_Execut_start_GPIOG4;
  /* USER CODE BEGIN EXTI15_10_IRQn 0 */
 
  /* USER CODE END EXTI15_10_IRQn 0 */
  HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_14);
  /* USER CODE BEGIN EXTI15_10_IRQn 1 */
Test_Execut_stop_GPIOG4;
  /* USER CODE END EXTI15_10_IRQn 1 */
}

0693W00000WKSYnQAP.png

ulao
Associate III

ok unlesss 1us is not enough time for the st to re arm the irq I think I the issue is code related. it seem to fire correctly the first time.

MM..1
Chief II

0693W00000WKSxiQAH.pngFor 12 and 180MHz for example 66,6ns plus interrupt init instruction cycles...