Many modern microcontroller have a cool feature: Pin Muxing. What it means is that I can ‘mux’ the pins for different purposes: such as I can use a SPI or I2C pin as GPIO (General Purpose Pin) or vice versa. In an ideal world, I would be able to ‘route’ or ‘mux’ pins freely around. In practice these ‘way switches’ are more or less limited.
In “Using the Reset Button on the Freedom Board as User Button” I muxed the FRDM-KL25Z reset pin as GPIO pin. The same approach can be used for muxing the NMI (Non-Maskable Interrupt) pin for the Freescale Kinetis devices. I’m showing it here how to do this with Processor Expert as this allows me to do this with a few mouse clicks.
I’m using in my example the FRDM-K64F board. If I want to configure a (BitIO) component to use the NMI pin, I get an error (screenshot with the new Processor Expert view in DriverSuite V10.4).
Hovering over the error gives me already the hint how to ‘fix’ it: I need to go to the CPU component which is already marked with an error flag:
💡 This cross checking and consistency checks are one of the big benefits to me using Processor Expert. If I would use ‘normal’ coding, these things easily get missed.
In the Cpu component properties, I see that the enabled NMI pin is causing the conflict:
So I have the NMI pin disabled:
As I do not need the NMI interrupt, I disable this in the CPU interrupts/reset section:
💡 The settings of interrupts and pin enable are connected and interlocked. In the earlier version of Processor Expert I had sometimes the issue that one setting was ‘grayed’ out. I had not a clear reproducible case, but it helped if I re-enabled the other setting to ‘unblock’ it.
That’s it. With this I have the NMI pin ‘muxed’ as normal GPIO pin.
💡 The same thing can be done for the reset pin. But here be careful: muxing the reset pin means that there is no way to reset the microcontroller with the reset pin. If I mux the pin early in the startup process, then this means the microcontroller boots and after a micro-seconds later the reset line is disabled. That might mean that the debug probe is not able to get control over the CPU, especially if low power mode is involved, or if this happens that fast. Your microcontroller still runs, but you need to be lucky (or fast enough) to get control over the CPU. I recommend to disable/mux the reset pin only a few second after power up to give the debugger a chance to get access to the CPU.
Happy Muxing 🙂