Hi,
when NMI pin is asserted (low level) during reset, then from very first instruction ICSR->VECTACTIVE contains 0x002 which I assume means that NMI interrupt vector is currently active and executing and it holds the 0x002 value forever preventing any other ISR to be executed. Deasserting or cycling NMI pin has no effect on ICSR->VECTACTIVE.
NMI handler is never executed - observed by adding a breakpoint inside NMI handler routine which is never hit. My program runs always main task (of course as VECTACTIVE == 0x002 prevents any other interrupt to beexecuted), so I don't understand how it is possible that ICSR->VECTACTIVE contains non zero value.
When NMI pin is deasserted during reset, than the program executes as expected. All interrupts works, falling edge on NMI pin triggers NMI handler to be exectued (if NMI pin is configured for NMI function)...
I tried this on on KL25 and KL02 MCUs.
Can someone explain this behaviour?
Hello Martin Dusek:
I tried with a FRDM-KL25Z and it is working as expected, jumping to the NMI interrupt handler just after reset and clearing the VECTACTIVE field.
What IDE and kind of project do you have (KDS, baremetal, MQX, Processor Expert)?
Can you share your test project so I can try from my side?
Regards!
Jorge Gonzalez
Dear Jorge,
I use CrossWorks for ARM and here is a project for KL25 - http://www.filedropper.com/nmi . When PTA4 is shorted to GND during reset, then ICSR->VECTACTIVE == 0x002 all the time. Putting PTA4 to 3V3 has no effect. Main task is executing but no interrupts will be able to run as the code runs "inside" NMI which is high priority vector.
My KL25 has 2N97F mask.
BTW: Is it possible to add file attachment directly to my post?
Hello Martin Dusek:
Please check the document posted by colleague Alistair explaining his response and a workaround in case it is the debugger causing the issue:
Interrupts appear to be disabled when debugging.pdf
About adding attachments, you can click on "Use advanced editor" in the upper right corner and then you will see the "Attach" option in the lower corner:
Regards!
Jorge Gonzalez
Martin,
When you see the issue that the code does not jump to the NMI handler is this when you have an active debug session running or in normal operation?
Some debuggers when they connect simply point the PC to the reset vector and do not check if the NMI is pending. This results in the code executing from reset without entering the NMI handler and the NMI is always pending. The NMI is a higher priority than the other NVIC interrupts and so blocks any lower priority interrupt.
Regards,
Alistair