AnsweredAssumed Answered

Hard Fault when disabling GPIO pin with interrupt configuration

Question asked by geoffs on Feb 7, 2017
Latest reply on Feb 9, 2017 by Kerry Zhou

I have an application where I wanted to initially configure a pin as a GPIO input, with an interrupt triggered on a falling edge, and then re-mux the pin to an alternative function.  It has been causing hard faults which I couldn't understand, so I have managed to recreate the issue with a very basic program on a FRDM-KL26Z board.  

 

See below code snippet which sets up Port A pin 13 as a GPIO input, configures it to generate an interrupt on a falling edge, enables interrupts for Port A, then attempts to re-mux the pin to disabled state.  A hard fault occurs at this point in the program.

 

CLOCK_EnableClock(kCLOCK_PortA);
PORT_SetPinMux(PORTA, 13U, kPORT_MuxAsGpio);
PORT_SetPinInterruptConfig(PORTA, 13U, kPORT_InterruptFallingEdge);
EnableIRQ(PORTA_IRQn); // this enable IRQ on all of Port A
PORT_SetPinMux(PORTA, 13U, kPORT_PinDisabledOrAnalog);

 

The code uses KSDK v2 commands for clarity, but the same fault occurs if the SDK function calls are replaced with the equivalent register read/write commands.

 

In the example above, the final re-mux was to disable the GPIO pin, but a hard fault occurs if it is re-muxed to other functions (Alt2, Alt3 etc).

 

Is anyone else able to replicate this behaviour ?  Is this expected behaviour ?  I haven't seen anything to suggest it is, but perhaps there is something buried in the ARM reference manuals which says not to change pin muxes when a pin is configured with interrupts.

 

If it is expected behaviour: what are the other options for either disabling or re-configuring the GPIO pin for alternative functions ??

Outcomes