2015-07-07 11:47 PM
I am using an STM32L151 (Cortex-M3) and configuring an external interrupt on a gpio pin:
/* Enable clocks */ RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_SPI3, ENABLE); RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA, ENABLE); RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOB, ENABLE); RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOC, ENABLE); RCC_APB2PeriphClockCmd(RCC_APB2Periph_TIM9, ENABLE); /* ExtInt Input */ GPIO_InitTypeDef GPIO_InitStr; GPIO_InitStr.GPIO_Speed = GPIO_Speed_40MHz; GPIO_InitStr.GPIO_Mode = GPIO_Mode_IN; GPIO_InitStr.GPIO_PuPd = GPIO_PuPd_DOWN; GPIO_InitStr.GPIO_Pin = GPIO_Pin_13; GPIO_Init(GPIOC, &GPIO_InitStr); /* Interrupts on EXTINT */ SYSCFG_EXTILineConfig(EXTI_PortSourceGPIOC, EXTI_PinSource13); EXTI_InitTypeDef ExtiInitStr = {EXTI_Line13, EXTI_Mode_Interrupt, EXTI_Trigger_Rising, ENABLE}; EXTI_Init(&ExtiInitStr); NVIC_InitTypeDef NvicInitStr = {EXTI15_10_IRQn, 0, 0, ENABLE}; NVIC_Init(&NvicInitStr);
My main.c eventually reaches a point where I have:
__enable_irq(); //...program related code.. __ASM volatile (''wfi'');
At this point, the processor does NOT wake up from a the external pin going high. If I replace the WFI line instead with
while(1);
the interrupt is triggered properly. I tried to follow examples but did not find something different. (I use ST-Link/V2 debugger, GNU Tools for ARM Embedded Processors Toolchain & Eclipse plug-ins, with gdb and openOCD, if this matters)
Am I missing something very obvious? #irq #stm32l1512015-07-08 11:44 PM
Would you say that it is impossible? Is this all that needs to be configured?
Perhaps it has something to do with the LowPower (LP) clocks? To my understanding they should be enabled by default, right?2015-07-10 08:22 AM
According to the documentation, WFI puts the processor simply in sleep mode, and any interrupt, especially EXT should wake him up.
Plus I am using PC13 which is for this chip a WKUP pin. But to use this function I would have to configure the pin as AlternativeFunction and not Gpio input and when I do that I get no interrupts at all (even with the while loop)2015-07-10 08:37 AM
STM32L1xx_StdPeriph_Lib_V1.1.1\Project\STM32L1xx_StdPeriph_Examples\RTC\TimeStamp\main.c
/* Configure PC13 in alternate function mode */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_13;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_40MHz;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOC, &GPIO_InitStructure);
/* Connect PC13 to RTC_AF1 */
GPIO_PinAFConfig(GPIOC, GPIO_PinSource13, GPIO_AF_RTC_AF1);
/* Connect EXTI13 Line to PC13 pin */
SYSCFG_EXTILineConfig(EXTI_PortSourceGPIOC, EXTI_PinSource13);
/* Configure EXTI13 line */
EXTI_InitStructure.EXTI_Line = EXTI_Line13;
EXTI_InitStructure.EXTI_Mode = EXTI_Mode_Interrupt;
EXTI_InitStructure.EXTI_Trigger = EXTI_Trigger_Falling;
EXTI_InitStructure.EXTI_LineCmd = ENABLE;
EXTI_Init(&EXTI_InitStructure);
Are you sure it doesn't come back? Depending on the power mode you could just be killing the debug connection.
2015-07-14 08:25 AM
This example assigns PC13 to an Alternate Function, not Gpio Input. But an external interrupt on gpio should work on any gpio, not just the WKUP pins.
If I set a gpio before the WFI command, and put a clearing command after the WFI and also in the irq handler, I see it staying set. The debug session seems still running. If I click halt and then step-over, I pass over the WFI interrupt (probably because halt woke the cpu up?) The register PWR->CR is 2048 before the command and PWR->CSR is 8. This means simple sleep mode I believe.2015-07-14 08:55 AM
Can you test it without the debugger attached?
2015-07-15 12:13 AM
I would like to but this is a different issue and it is better to start a new thread:
The program does not run (reach the main at least) if I power it on without the debugger. NRST is pulled high and I can touch it to low, the program is flashed on 0x0800 0000 and the part starting from 0x0 seems to be a copy of 0x0800 0000. I am flashing the hex file the compiler gives and when debugging the elf is loaded (gdb/openocd/st-linkV2isol). I think the reset vector is properly linked and leads to the startup sequence, the bss inits and eventually main(). The linker includes stabs debugging sections, if that is a problem.. My problem was actuallysolved by decreasing the PLL speed
. My config is: /* HCLK = SYSCLK /1*/ RCC->CFGR |= (uint32_t)RCC_CFGR_HPRE_DIV1; /* PCLK2 = HCLK /1*/ RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE2_DIV1; /* PCLK1 = HCLK /1*/ RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE1_DIV1; /* PLL configuration */ RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLMUL | RCC_CFGR_PLLDIV)); RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_HSI | RCC_CFGR_PLLMUL6 | RCC_CFGR_PLLDIV3); And I verify that the problem is fixed when I replace the bold part with RCC_CFGR_PLLMUL3. I cannot explain this, I don't know if it is related with the debugger speed or anything else.