A problem with __HAL_GPIO_EXTI_CLEAR_IT on Nucleo-F410RB Optimization -03 (stm32cubeide)

It takes time until the interrupt source clear propagates into NVIC.

JW

Ha OK,

Thank you.

And is there the same phenomenon when propagating the interrupt signal?

Because in this example, it appears that the code is not immediately interrupted when the reason for the interruption appears (rising edge of the first pulse).

(The PA5 output is connected to the PC1 input).

Thanks again in advance for your help.

void EXTI1_IRQHandler(void)

{

       GPIOA->BSRR = GPIO_PIN_6;

       GPIOA->BSRR = GPIO_PIN_6<<16u;

       __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_1);

       __NOP();

}

//#############################################

int main() {

HAL_Init();

SystemClock_Config();

MX_GPIO_Init();

 HAL_NVIC_SetPriority(EXTI1_IRQn, 0, 0);

 HAL_NVIC_EnableIRQ(EXTI1_IRQn);

while (1) {

GPIOA->BSRR = GPIO_PIN_5;

GPIOA->BSRR = GPIO_PIN_5 <<16u;

}

}

Yes that's exactly the same.

When interrupt is exit, PA5 in main() starts to pulse again, and the first active edge (depending on which edge is set in EXTI) sets the interrupt flag in EXTI; but it takes 2 more PA5 pulses (i.e. estimating pulse to be high for 1 system cycle and low for 3, it's at least 8 system cycles) until that signal propagates all the way to NVIC and starts the interrupt.

A very nice visualisation of the problem indeed, thanks.

JW

Thank you.

Actually I am in the process of migrating from avr to arm ... so I am studying this core .

Just for information, the 3 cycles of the low state are actually 1 cycle + 2 cycles of sequence break (1 cycle of jump + 1 flush of a 1/3 of the pipeline). I had actually estimated 8 cycles but I am continuing my study to get a more deterministic answer.

Thank you again for your clarifications. I had not yet studied the bus times well.

Hi VAX, when you go from avr you know NAKED irq, And your problem here is i mean missusing HAL system. When you generate code from cube IRQ is defined in three function level calls, where you edit only last callback level. And difference in 030 vs 410 maybe is based on used clock config aka speed.

when IRQ occured as first it jump

EXTI15_10_IRQHandler

here call only

HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_13)

here check and clear flags and if this gpio have flag call

HAL_GPIO_EXTI_Callback

here your code an i mean will work with -O3 , but when you need special you can NAKED and dont use an HAL or __HAL

Thank you MM..1 for your reply.

I'm sorry, but English is not my native language and I may have misunderstood your answer.

In my case, the ivt is initialized as follows:

g_pfnVectors:

 .word _estack

 .word Reset_Handler

 …

 .word    RCC_IRQHandler                   /* RCC                                        */

 .word    EXTI0_IRQHandler                 /* EXTI Line0                                 */

 .word    EXTI1_IRQHandler                 /* EXTI Line1                                 */

...

my isr is :

//---------------------------

void EXTI0_IRQHandler(void)

{

   GPIOA->BSRR = GPIO_PIN_6;

   GPIOA->BSRR = GPIO_PIN_6<<16u;

    EXTI->PR=GPIO_PIN_0;

    // __NOP(); // Avec un NOP : comportement normal.  Sans le NOP => 2 impulsions !!!

}

My ISR is therefore immediately invoked and I do not use the 3 steps of HAL (I don’t want because I'm in the study phase of this core, I'm only using Cube to generate quickly the code for the clock configuration).

I tried to recreate these multiple calls and the result is the same. It seems necessary to leave at least one waiting cycle between the flag reset and the rti ("BX LR") for this to work.

Converting my isr to “nacked isr�? will only remove the prefix and postfix, this will save a few cycles but the problem remains the same.

I conclude that it is best to reset the EXTI flag early enough in the ISR code and the problem is then resolved.

Thank you all for your contributions.

Hi VAX , my native isnt english too...

You write recreate multiple calls, but i mean not right. I check it on Cube generated code seems this:

in it.c

/**

 * @brief This function handles EXTI line0 interrupt.

 */

void EXTI0_IRQHandler(void)

{

 /* USER CODE BEGIN EXTI0_IRQn 0 */

 /* USER CODE END EXTI0_IRQn 0 */

 HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0);

 /* USER CODE BEGIN EXTI0_IRQn 1 */

 /* USER CODE END EXTI0_IRQn 1 */

}

in hal

/**

 * @brief This function handles EXTI interrupt request.

 * @param GPIO_Pin Specifies the pins connected EXTI line

 * @retval None

 */

void HAL_GPIO_EXTI_IRQHandler(uint16_t GPIO_Pin)

{

 /* EXTI line interrupt detected */

 if(__HAL_GPIO_EXTI_GET_IT(GPIO_Pin) != RESET)

 {

  __HAL_GPIO_EXTI_CLEAR_IT(GPIO_Pin);

  HAL_GPIO_EXTI_Callback(GPIO_Pin);

 }

}

in main.c your implementation

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)

{

GPIOA->BSRR = GPIO_PIN_6;

GPIOA->BSRR = GPIO_PIN_6<<16u;

}

And as you can see HAL define call clear before user code... Thats all

I was not clear, I'm sorry ...

What I meant is that I am familiar with how Cube / HAL generated code works, and I am also familiar with this nested call.

It was by analyzing this code that I wanted to understand why the clear was made at the start of the HAL_GPIO_EXTI_IRQHandler function

I recreated the calls to prove that just because there is a two-level call graph, of isr, doesn't make it work better. Just because we spend a little time going up two levels doesn't mean that is enough. it is indeed a cycle problem between the reset and the break in the sequence (exit of isr). If the flag reset was done after invoking the callback (we can, just for fun, inverse the call of the callback and de clear_it() ) there could be the same problem because, my analysis is that there must be clock cycles between the write into EXTI-> PR and the “bx lr�? . When it does, all is well, but, if the compiler generates an output of isr immediately after the flag is reset, it doesn't work. if there are no OpCode between EXTI->PR= and "BX LR", it doesn't work.

Now, i must ubderstand why it's like this, i go to continue searching

I have a problem with the language barrier, I'm sorry. So we were talking about the same thing.

I started to manipulate and partly understand HAL but now I'm going down lower level to better understand how this MCU works. That's why I ask myself all these questions

Anyway, thank you for spending time answering me

Take a look at this:

https://developer.arm.com/documentation/dai0321/a/

Section: 4.9 Disabling interrupts at peripherals