MKL03 crashing after waking up from VLSS3.

[carlos_takeo_ta]

Hello NXP support.

I'm debugging an application made for the MKL03Z32VFK4R.

The system is powered by a 3 volt battery and remains in VLSS3 low consumption mode most of the time.

The LLWU_P4 pin, which in this MCU (microcontroller) is PTB0, is configured as wake-up on a positive edge.

There is a switch connected to PTB0 and when pressed, it causes a positive edge that wakes up the MCU.

After waking up, some tasks are executed and at the end it returns to VLLS3 mode.

The application works correctly, but sometimes crashes intermittently.

I made some captures using a PPK2 (Power Profiler Kit 2) from Nordic Semiconductors.

I connected the PPK2 configured as a 3 volt power supply in place of the battery.

This way I rule out the possibility of a low battery.

I also connected the second USB of the PPK2 to guarantee up to 1000 mA of supply capacity.

I also connected an I/O pin from the MCU to digital input D0 on the PPK2.

I programmed the I/O pin to toggle each executed line of code, initially with the aim of finding out where it was stuck.

Below I present a set of figures:

figure01: shows a succession of successful PTB0 switch pressing cycles;

figure02: shows in detail a cycle that worked.

figure03: shows the cycle that stopped, observing the timeline, in this case it took a little more than 5 minutes and 28 seconds to stop;

figure04: shows a crash cycle, but the MCU has recovered;

figure05: shows in zoom the final part of the cycle that almost stopped. Notice that D0 starts to show toogle dynamics, apparently similar to figure04.

I did several tests and found that the problem is intermittent.

Sometimes the crash occurs in the first few cycles and sometimes it takes a long time, as in this case, which occurred after more than 5 minutes.

I thought of several hypotheses:

1 - I thought it could be the ACKISO flag not being "cleared" after the wake-up of VLLS3.

But the MCU continued to crash, even "clearing" the ACKISO flag unconditionally.

I commented out the line that clears ACKISO, just to see if I could crash the MCU.

Surprisingly, the MCU didn't crash and worked as if it didn't make a difference.

2 - Initially the program called a function "InitLLWU" that configures the LLWU to detect positive edge on pin LLWU_P4 (PTB0) and enables the LLWU interrupt.

Then a function "enter_vlls(3)" is called to enter VLSS3 mode.

I tried placing the "InitLLWU" function inside the "enter_vlls(3)" function, in this case, I placed "InitLLWU" one line before calling __WFI.

I thought the reason for the crash would be an LLWU interruption happening before the MCU entered VLSS3 mode, but even after this change, the crash occurred.

3 - At first I thought that the crash shown in figure 03 indicated that the MCU woke up and the restart corrupted and crashed the MCU.

There were also cases like the one seen in figures 04 and 05 that looked like a case of crash, but the MCU managed to recover.

Although toggles do not occur in the initial part of figure 04, in the final part, seen in figure 05, the toggle dynamics are very similar to those seen in figure 02.

At first I thought the problem could be due to poor settings before entering VLLS3.

Even though the cycle was not valid, the MCU managed to recover, so I think the problem is happening after waking up, perhaps the unsuccessful partial reset, or some failed initialization.

These were the tests and conclusions I have drawn so far.

If anyone has had a similar experience and can give me any suggestions, I would be grateful.

Best Regards.

[Celeste_Liu]

Hello @carlos_takeo_ta ,

Thanks for your post. I think this may be related to ERR008010. Please check whether PMC_REGSC[ACKISO] is cleared and whether the corresponding flag of the comparator in the LLWU_Fx register is cleared. Correspondingly, it provides a workaround.

KL03Z Errata Link: KL03Z_1N86K 

Hope it help you. If you have any further questions or need more information, please let me know.

Best Regards,

Celeste

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

[carlos_takeo_ta]

Hi Celeste_Liu, thank you very much for the feedback.

I am not using the CMP comparator module in my project.
Do you think that even so, the ERR008010 errata would be relevant?
Anyway, could you show me what the code suggested by the workaround would look like?

Best Regards.

[Celeste_Liu]

Hello carlos,

You are correct. Since CMP was not used, it should have nothing to do with this errata.

I would suggest you refer to the power manager demo under the SDK installation folder

SDK_2.3.1_FRDM-KL03Z\boards\frdmkl03z\demo_apps\power_manager

This demo application demonstrates the use of power modes in the SDK. and use source pin to wake up from VLLS3.

SDK download link: Select Board | MCUXpresso SDK Builder

Hope it can help you.

BRs,

Celeste

[carlos_takeo_ta · Accepted solution]

Hi Celeste_Liu, sorry for the delay in responding.

I managed to discover the problem.
The problem was not related to the low power mode, but rather to pin 19 of the MKL03Z32VFK4R.
I discovered that pin 19 returns to the default configuration, which is the NMI (Non-Maskable Interrupt) function, after the partial reset that occurs after wake-up.
I use pin 19 as GPIO input, that is, as PTB5 to read the state of a switch.
I believe that after the reset, some noise was activating the NMI handler before it was possible to configure the pin as PTB5.
As I don't use the NMI function, I saw that the default NMI handler is a while(1){} loop that locks the processor.
I solved the problem by disabling the NMI option, according to the guidance I found in the post: https://community.nxp.com/t5/MCUXpresso-General/debug-problem-on-KL03Z8/m-p/949741
I changed Flash_Config word4 to 0xFFFF3BFE and did many tests to confirm that the problem had been resolved.

I thank you for the support.