AnsweredAssumed Answered

KL02Z External Interrupt ISR not called

Question asked by Richard Gagliardo on Jan 9, 2018
Latest reply on Jan 26, 2018 by Richard Gagliardo

Hi all,

I'm working on a project using a KL02Z controller and am trying to configure the Port B pin 5 as an interrupt. I'm using the MCUXpresso IDE.


I've configured the pin as an input and set the interrupt to trigger on a falling edge:

PORT_SetPinInterruptConfig(PORTB, PIN5_IDX, kPORT_InterruptFallingEdge); /* Set PORTB5 (pin 13) to interrupt on falling edge */

Note: Pin5_IDX is defined as 5U.

This actually calls a macro:

static inline void PORT_SetPinInterruptConfig(PORT_Type *base, uint32_t pin, port_interrupt_t config)
base->PCR[pin] = (base->PCR[pin] & ~PORT_PCR_IRQC_MASK) | PORT_PCR_IRQC(config);

Next the interrupt is enabled:


This calls another inline macro:

NVIC->ISER[0U] = (uint32_t)(1UL << (((uint32_t)(int32_t)IRQn) & 0x1FUL));


When I run the code and toggle the input to pin 13 on the CPU, I see that the PORTB->PCR[5] has the value of 0x010a0105. That indicates that the ISF flag has been set, so the interrupt has triggered. 

Additionally, the PORTB->ISFR indicates a value of 0x20, which also indicates that the interrupt has triggered.


Looking at the NVIC->ISER, the value is 0x80020400. The fact that Bit 31 is set indicates that the PortB interrupts should be enabled.

The NVIC->ISPR is similar: the value is 0x80000400, indicating that the PortB interrupt is pending.


Looking in memory at address 0x000000BC I see that the 32 bits there are 0x00001150, which is not the default handler but my ISR, so I think I've got that setup OK.


Finally, at the end of the processor init routine I have the statement:

__ASM volatile ("cpsie i" : : : "memory"); // Enable IRQ

which enables the maskable interrupts, so I'm assuming that isn't an issue.


What I don't see is the tool stop at my first statement in the ISR, which is where I increment a global variable. That variable is still at zero, indicating that the ISR hasn't been called.


Oh, one final thing - when I halted the execution to look at the variables the processing was in a while look in my main code (just spinning for now), so I don't think it's a matter of the ISR being starved for attention.


Any suggestions?


Thanks so much in advance.