Kinetis NMI after reset

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Kinetis NMI after reset

1,972 Views
martindusek
Contributor V

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?

Labels (1)
4 Replies

905 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

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

0 Kudos
Reply

905 Views
martindusek
Contributor V

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?

0 Kudos
Reply

905 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

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:

Attach.png

Regards!

Jorge Gonzalez

0 Kudos
Reply

905 Views
al_muir
NXP Employee
NXP Employee

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