STM32l052 exti problem

[baev_al]

Posted on August 22, 2015 at 20:27

Hi.

I have three buttons connected to PB12, PB13, PB14.

I use the following code:

  GPIO_InitStruct.Pin = GPIO_PIN_12 | GPIO_PIN_13| GPIO_PIN_14;

  GPIO_InitStruct.Mode = GPIO_MODE_IT_RISING;

  GPIO_InitStruct.Pull = GPIO_NOPULL;

  HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);  

  HAL_NVIC_SetPriority(EXTI4_15_IRQn, 1, 0);

  HAL_NVIC_EnableIRQ(EXTI4_15_IRQn);

void EXTI4_15_IRQHandler(void)

{

}

Exactly in this case the program always gets to the EXTI4_15IRQHandler because of pin13. And I cannot reset it. When I exclude this pin

GPIO_InitStruct.Pin = GPIO_PIN_12 | GPIO_PIN_14;

I can get to the IRQ handler pushing only button connected to pin14, pin12 button doesn't have any effect. However if I exclude pin14

GPIO_InitStruct.Pin = GPIO_PIN_12;

pin12 button works properly.

What can I check? Is it the compiler? (I use EWARM 7.20 with no optimization option)

[baev_al]

Posted on August 23, 2015 at 20:45

In addition to the previous post...

I tried different optimization modes of the EWARM. I installed Keil 5.16 - the same situation. When I connect more then one button to  the EXTI (one of PB12, PB13, PB14) - interrupt handler does not work properly. Is it hardware bug? I need exactly this lines because the PCB is already made for these lines...

[Tesla DeLorean]

Posted on August 23, 2015 at 23:30

Ok, but what exactly is wired up here. A push switch to VCC? Is there a pull-down to GND when it's open, or does it float? Should you enable the GPIO with a pull-down?

Do you have anything in your IRQHandler? What do the GPIO, EXTI and NVIC registers reveal?

You avenues here are to review the Reference Manual, and perhaps implement register code using the fragments library to confirm if the issue is on the hardware side (yours?, ST's?) or the software side.

[baev_al]

Posted on August 24, 2015 at 08:37

I attached the schematic.

Here is my IRQ code:

void EXTI4_15_IRQHandler(void)

{

if(__HAL_GPIO_EXTI_GET_IT(GPIO_PIN_12) != RESET)

{

__HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_12);

LCD5110_set_XY(0,1);

LCD5110_write_string(''12'');

}

if(__HAL_GPIO_EXTI_GET_IT(GPIO_PIN_13) != RESET)

{

__HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_13);

LCD5110_set_XY(0,1);

LCD5110_write_string(''13'');

}

if(__HAL_GPIO_EXTI_GET_IT(GPIO_PIN_14) != RESET)

{

__HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_14);

LCD5110_set_XY(0,1);

LCD5110_write_string(''14'');

}

}

Watching GPIOB IDR while stepping through the code's lines and pushing different buttons I see changing on the according IDR lines.

What is strange is that when I leave just any one of the button lines - everything works great. Adding any other lines ruins the execution.

The worst case - all three buttons. EXTI PR line 13 always stays as pending (''1''), the code goes to the IRQ handler but does not reset PR... What should I check in the NVIC registers?

PS. Replaced the STM32L052 chip - absolutely identical problem...

________________

Attachments :

Temp_contr.PDF : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0gi&d=%2Fa%2F0X0000000bcU%2FE8k8YGx0dWmCSapb_ufRng5rN5l40kgZMEZTNyLbuMs&asPdf=false

[baev_al]

Posted on August 25, 2015 at 12:44

EXTI continued...

I connected buttons thus that 3 different EXTI IRQ handlers became involved: PB0, PB2, PB14. Now I managed to get two buttons of three - one of three buttons didn't trigger the interrupt.

Only when I connected buttons this way: PA0, PB2, PB14 all three EXTI IRQ handlers started to work.

I would appreciate to get comment of ST team on this. It seems I did everything right. Is this a chip bug?

[andrealombardo9]

Posted on October 18, 2015 at 05:54

Hi,

I got exactly the same problem.

On my opioni is a bug in the HAL_Gpio_Init function.

The line:

        temp &= ~((uint32_t)0x0F) << (4 * (position & 0x03));

should be:

        temp &= ~(((uint32_t)0x0F) << (4 * (position & 0x03)));        

otherwise the ~ does not work on the final output of the shift and the mask is wrong. The result is that when you configure the second EXTI, you delete te configuration of the previous EXTI in the same SYSCFG_EXTICR register.

With the modified line, it works.

Andrea

[Nesrine M_O]

Posted on October 21, 2015 at 19:21

Hi Andrea,

It is a known bug, but the fix is already released on the STM32CUBEL0 V1.3.0.

-Syrine-