ARM Cortex M NonMaskable Interrupt is NonClearable also?

0
votes

I am working with a very custom and not public Secure IC which has ARM Cortex M3 core.

In case of hw security violation, this IC triggers an NMI interrupt so it is fine, I am doing whatever I need for violation.

But It always enters into NMI Handler again and again when a violation is occurred.

We probably need to clear interrupt pending flag not sure but it should be cleaned directly. Because SCB->ICSR bit31 says that "entering the handler clears this bit to 0".

I also tried to clear pending flag using NVIC_ClearPendingIRQ() but it does not accept negative IRQ values while NMI is -14.

I tried to set manually NVIC->ICPR[0] = (1 << 2); like as manufacturer examples (but manufacturer example resets device in NMI handler which is different case) but it does not work.

It is custom IC and custom external event which triggers generic Cortex M NMI interrupt and can be a specific case to IC but is there any limitation for NMI like "you can not clear NMI pending flag and you have to reset it bla bla"?

Thank you

1
arminterrupt-handlingcortex-m3
as with any interrupt you need to clear it from the source otherwise it may re-trigger depending on the design of the interrupt manager/handler cpu core, etc... - old_timer
which would be in your portion of the IC, not the arm IP. - old_timer

1 Answers

1
votes

The NMI is acting just like any other interrupt here.

From the Cortex-M Generic Device User Guide:

  • For a level-sensitive interrupt, when the processor returns from the ISR, the NVIC samples the interrupt signal. If the signal is asserted, the state of the interrupt changes to pending, which might cause the processor to immediately re-enter the ISR. Otherwise, the state of the interrupt changes to inactive.
  • For a pulse interrupt, the NVIC continues to monitor the interrupt signal, and if this is pulsed the state of the interrupt changes to pending and active. In this case, when the processor returns from the ISR the state of the interrupt changes to pending, which might cause the processor to immediately re-enter the ISR.

What this is saying is that unless you clear the hardware state which is generating the interrupt request, the interrupt will pend again.

Clearing the interrupt pending state only allows you to disable an IRQ if the request has already been cleared.

For details on how your secure device operates, you need to speak to your vendor. They may be unhappy about you discussing their product here...