Hi Nadine
I don't know the SDK code but it may be that it expects you to clear the interrupt source in the user callback. If you don't it may be stuck in the interrupt (?). If it hangs "during" initialisation it may expect you to previously enable clocks to the port in question (?).
You could also look at uTasker code to do this -
extern void fnConfigInterrupts(void)
{
INTERRUPT_SETUP interrupt_setup;
interrupt_setup.int_type = PORT_INTERRUPT;
interrupt_setup.int_priority = PRIORITY_PORT_C_INT;
interrupt_setup.int_port = PORTC;
interrupt_setup.int_port_bits = PORTC_BIT1;
interrupt_setup.int_port_sense = (IRQ_BOTH_EDGES | PULLUP_ON);
interrupt_setup.int_handler = myInterrupt1;
fnConfigureInterrupt((void *)&interrupt_setup);
interrupt_setup.int_port_bits = PORTC_BIT2;
interrupt_setup.int_port_sense = (IRQ_FALLING_EDGE | PULLUP_ON);
interrupt_setup.int_handler = myInterrupt2;
fnConfigureInterrupt((void *)&interrupt_setup);
interrupt_setup.int_port_bits = PORTC_BIT3;
interrupt_setup.int_port_sense = (IRQ_HIGH_LEVEL | PULLDOWN_ON);
interrupt_setup.int_handler = myInterrupt3;
fnConfigureInterrupt((void *)&interrupt_setup);
}
static void myInterrupt1(void)
{
}
static void myInterrupt2(void)
{
}
static void myInterrupt3(void)
{
}
This sets three different interrupts on Port C with their own characteristics and individual call-back handler (and can be used to enter DMA triggers or LLWUs). It also allows you to simulate the complete operation in the K64 simulator so that you can test complete code, interrupts, DMA etc. in order to avoid difficulties, to easily understand errors or learn the internal workings.
Unlike SDK any code that you write can be run on any Kinetis part (K, KL, KV, KM, KW) without needing porting and also builds with KDS3.x, CW10.x, IAR, Keil, Rowley, Atollic, Green Hills, CooCox, GCC, VisualStudio so is not restricted to particular environments.
Regards
Mark
K64 support:
µTasker Kinetis FRDM-K64F support
µTasker Kinetis TWR-K64F120M support
µTasker Teensy3.5 support