VLLS LLWU Causing NMI

[nick_schneider]

Setup

MCU: MKL16Z128VFT4

SDK: SDK_2.x_MKL16Z128xxx4 v2.2.0

IDE: MCUXpresso v24.9

Main Issue and Questions

I am attempting to use VLLS3 but it appears that the NMI is being triggered when the LLWU interrupt is triggered which results in the watchdog triggering 1 second later.

1. Why does NMI get triggered when I am utilizing the NMI pin as a GPIO?
2. Why does the NMI pin go high when the LLWU interrupt is triggered?
3. Why does the watchdog trigger if I am disabling at startup? Does it get reenabled during a VLLSx/LLWU reset?
4. I can remove the infinite while loop in the NMI default handler and this fixes the issue but this seems like a hack to me. What is the proper way to deal with the NMI? Is there a way to prevent it from triggering?

Background

I have been working on utilizing the VLLS3 sleep mode for the first time. I am accustomed to using the LLS sleep mode so with VLLS3 I need to worry about the reset flow that happens with the LLWU. I am running into an issue where I cannot wakeup properly. The LLWU does seem to trigger as expected but the firmware seems to get hung up and the watchdog triggers 1 second after the LLWU even though I am attempting to disable the watchdog immediately at startup. It appears that the firmware gets stuck in the default NMI handler based on the fact that it does not get stuck if I remove the infinite while loop in that function. I am utilizing the NMI pin as a GPIO that is used to enable an IC and the pin has a weak external pulldown. I will add a drawing for this part of the system. Despite setting up the pin in this way, the pin appears to go high when the LLWU is activated which I do not understand why.

I am attaching a drawing for the NMI pin circuit and a sample project where I am seeing this issue. Any information that helps me understand this situation would be very helpful. 

[Celeste_Liu · Accepted solution]

Hello @nick_schneider ,

Thanks for your post. 

Have you modified the NMI_DIS bit in the FOPT register?  You need to set this bit to 0 to disable the control for the NMI function. Please refer to the screenshot from the RM below.

Celeste_Liu_2-1749203420946.png

Celeste_Liu_0-1749202916761.png

The data in the flash configuration field are copied to register automatically after Reset.
The data in 0x40D is copied to FOPT register.

Celeste_Liu_1-1749203142781.png

Form software configuration, the SDK has the array. For MCUXPresso, its path is startup/startup_mkl16z.c:

Celeste_Liu_4-1749204556288.png

Hope it can help you.

BRs,

Celeste

-----------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the "ACCEPT AS SOLUTION" button. Thank you!
-----------------------------------------------------------------------------------------------------------------

[nick_schneider]

Do you know why the NMI is being triggered specifically on LLWU from VLLS3? I would assume the LLWU reset is pretty much like a power up reset but the NMI doesn't happen on the power up reset. Also, the NMI pin does not go high on power up reset either as far as I know.

[Celeste_Liu]

Hello @nick_schneider ,

In the RM, you can see the explanation: In addition to the LLWU wakeup sources, the device also wakes from low power modes when NMI or RESET pins are enabled and the respective pin is asserted.

Celeste_Liu_0-1749521001474.png

Have a nice day.

BRs,

Celeste

[nick_schneider]

I do not believe that the NMI is the wakeup source in this situation. The NMI never activates on its own. The NMI will only activate after a different LLWU is triggered during VLLSX. In my sample project for example, the wakeup is caused by the LPTMR at a consistent interval and then the NMI is triggered. Its almost as if the NMI pin that I want to use as a GPIO is reverting back to its default state as the NMI trigger and also activates an internal pullup. But that does not explain why I do not see the NMI at power-up.

Is that what happens during a wake-up from VLLSX, do the MCU pins get set back to their default state until they are reinitialized by firmware?

[Celeste_Liu]

NMI_PIN is special pin in KL series. If the NMI function is not required, either for an interrupt or
wake up source, it is recommended that the NMI function be disabled by clearing NMI_DIS in the FOPT register.

When the system exits reset, the processor sets up the stack, program counter (PC), and link register (LR). The processor reads the start SP (SP_main) from vector-table offset 0. The core reads the start PC from vector-table offset 4. LR is set to 0xFFFF_FFFF. The next sequence of events depends on the NMI input and FTFA_FOPT[NMI_DIS]:
• If the NMI input is high or the NMI function is disabled in FTFA_FOPT, the CPU begins execution at the PC location.
• If the NMI input is low and the NMI function is enabled in FTFA_FOPT, this results in an NMI interrupt. The processor executes an Exception Entry and reads the NMI interrupt handler address from vector-table offset 8. The CPU begins execution at the NMI interrupt handler.

[nick_schneider]

Thank you, it looks like this is the proper way to avoid a NMI during a VLLSx wake-up.