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 ??
