KL03Z32 Stuck in VLLS3 After Programming

[james5]

I have a very strange problem, hopefully someone can point me in the right direction.

I have a device that goes into VLLS3 mode and wakes up via the LLWU_P4 connected to a push button.  In general this works very well.

However, there is one case where the device will NOT wake up.  This happens when a battery is connected (it's a battery powered device, and for various reasons it is a possible configuration during production) and the device is programmed by the PE Micro Cyclone.  This is configured to NOT provide power as the battery is doing so.

I've done some debugging and say that the problem can easily be repeated.  There are 2 paths in the code that put the device into VLLS3:  one when the button is pressed on power up and released quickly, the other when the button is pressed for a longer period of time.  By adjusting the code, both paths create the same issue.

The issue is, that after programming and releasing the reset, the device will boot, pass through one of the 2 paths, go to sleep, and then won't wake up again no matter how many times you push the button, or how long.

A short of nRST to GND will cause the micro to reset and then it behaves as expected.  I've also noticed that simply plugging the cable into the Cyclone can also, sometimes, cause the code to start running.  I suspect that it may be causing a glitch on the nRST line and just causing a reset.

If I program without the battery and then connect the battery, the device behaves as expected all time time.

Any ideas on what could call this.  Below is my code for the function that I call to put the device into VLLS3 as well as the LLWU IRQ handler.  I'm aware of the bug where the chip won't go into VLLS3 if an RTC flag is set (see code below).  But this isn't the problem, I can't get out of deep sleep.

Any ideas?

void LLWU_IRQHandler(void)
{
    PORT_SetPinInterruptConfig(nUSER_BUTTON_PORT, nUSER_BUTTON_PIN, kPORT_InterruptOrDMADisabled);
    PORT_ClearPinsInterruptFlags(nUSER_BUTTON_PORT, (1U << nUSER_BUTTON_PIN));
    LLWU_ClearExternalWakeupPinFlag(LLWU, LLWU_WAKEUP_PIN_IDX);
    NVIC_ClearPendingIRQ(LLWU_IRQn);
} // LLWU_IRQHandler()

void go_into_deep_sleep( void )
{
    // disable the 5V EN pin so there is no path to 5V rail during VLLS3
    PORT_SetPinMux( EN_5V_PORT, EN_5V_PIN, kPORT_PinDisabledOrAnalog );

    // turn off interrupts that have been enabled so these don't wake device up

    TPM_DisableInterrupts( TICK_TPM, kTPM_TimeOverflowInterruptEnable );
    NVIC_DisableIRQ( TICK_TPM_IRQ_NUM );

    // clear flags and configure to wake up from LLWU pin
    NVIC_EnableIRQ( LLWU_IRQn );
    NVIC_ClearPendingIRQ( LLWU_IRQn );
    LLWU_ClearExternalWakeupPinFlag( LLWU, LLWU_WAKEUP_PIN_IDX );
    LLWU_SetExternalWakeupPinMode( LLWU, LLWU_WAKEUP_PIN_IDX, kLLWU_ExternalPinFallingEdge );

    // clear RTC invalid time flag as per errata e8068 found in document KL03Z_1N86K

    // on some versions of die this will keep micro from entering power mode
    // RTC must be started and initialized or this call will freak out, which can happen if
    // button debounce kicks in and goes to sleep before RTC initialized
    if( RtcStarted )
    {
      RTC_StopTimer( RTC );
      RTC_ClearStatusFlags( RTC, kRTC_TimeInvalidFlag );
      RtcStarted = 0;
    }

    // set power mode to VLLS3
    smc_power_mode_vlls_config_t vlls_config;
    vlls_config.enablePorDetectInVlls0 = false;
    vlls_config.enableLpoClock = false;  // needs to be enabled for digital filtering on pin
    vlls_config.subMode = kSMC_StopSub3;

    SMC_PreEnterStopModes();
    SMC_SetPowerModeVlls(SMC, &vlls_config);
    SMC_PostExitStopModes();
} // void go_into_deep_sleep()

[diego_charles]

Hello james@stratforddigital.ca‌

I´ve received a reply from PEmicro, they are working on the issue.

When I get data  I'll let you know. 

Best regards, Diego

[diego_charles]

Hi, james@stratforddigital.ca‌

I´m waiting for confirmation, to see if is possible to execute code from the processor to exit from debug mode. By now it seems that the only way is through the SWD interface,  using an external debug probe. 

Additionally, to double-check we are on the correct path. Could you confirm to me, that the issue does not appear with another debugger/programmer, that is not related to PEmicro? 

Sorry for any inconvenience. 

Best regards, Diego. 

[james5]

Hi diego.charles‌, I can't do a 1:1 comparison since I don't have the same setup with other tools.  I did use the LPC-LINK2 for all of the development and never saw this problem.

Could you reach out to PE Micro to give them the details so they could verify if this issue is something with their system?  I'm sure they'd want to know...  and I need a solution.

James.

[diego_charles]

Hello, james@stratforddigital.ca‌

I´ll contact PEmicro today and let you know their resolution!

Please bear with me during the process. 

Best regards, Diego!

[diego_charles]

Hello, James Morrison

Sorry for my late response.

To help you further,  can you help me with the following inquiries?

• Both paths are intended to be used after reset only or can also drive the MCU to  VLLS3 at any time?
• How did you check that the MCU is stuck in VLLS3?
• Voltage drop and current consumption on the MCU for example :

        When the MCU can not exit VLLS3 and when it is capable.

• Core frequency  
• Battery type, nominal voltage, and current.

 I´m concerned if exists a considerable drop in the battery voltage and current during programming. that leads to this problem. 

Best regards, Diego

[james5]

Hi Diego, let me answer your questions:

• Both paths are intended to be used after reset only or can also drive the MCU to  VLLS3 at any time?

The general function of the device is to wakeup on the LLWU pin being pressed, do its business, and then go back to sleep.  That is one path to getting to VLLS3.  The other is, on startup, it does some debouncing on the button press, so that if it was only a really short glitch, it will then go back to sleep.  This is the other path.  Both are valid paths during actual use.  And I see the same behaviour after programming no matter which path is taken (to get the first one described here, I just hold down the button during programming so that it wakes it passes the debouncing and runs the main code right away).

• How did you check that the MCU is stuck in VLLS3?

I know that the current drawn is in the order of 5-8uA, so that is how I know.

• Voltage drop and current consumption on the MCU for example :

        When the MCU can not exit VLLS3 and when it is capable.

When running the normal code, the circuit draws 5-10mA. When it is in VLLS3, it consumes 5-8uA.

• Core frequency  

The core runs at 48MHz during normal operation.  Turns off in VLLS3 mode.  No other power modes or core frequency changes.

• Battery type, nominal voltage, and current.

Nominally 2.7V (up to 3.1V) or so, can supply pulses up to 15mA max. Lithium-ion non-rechargeable.

The PE Micro Cyclone has a 3.3V supply voltage, but I don't enable its power relays, so it does not provide power during programming.  Maybe there is a path from the VCC to 3.3V through pull-up resistors inside the Cyclone?

 I´m concerned if exists a considerable drop in the battery voltage and current during programming. that leads to this problem.

Can you explain this last sentence a bit more?  What sort of problem?  What would be a "considerable drop"?

James

[diego_charles]

Hello, james@stratforddigital.ca‌

Sorry for my late response and any inconvenience.  I´m still working on your question.

Thank you for your answers!  I wanted to know if the battery provides the voltage ( min 1.71v ) and current (max around 7mA ) necessary to ensure the reliable operation of the MCU. Sorry for any misunderstanding.

Moving forward to the programmer set up, when the programmer gets disconnected,  the MCU  can wake up successfully at any time using LLWU_P4. Is that correct? 

 When the MCU failed to wake up, did you had a debug session running? When entering VLLS, the debugger could experience a hang-up that alters posterior code execution.

  Maybe there is a path from the VCC to 3.3V through pull-up resistors inside the Cyclone?

Currently, I can not tell you if that could be possible because I don't have a Cyclone programmer with me. Additionally, it is possible for you to replicate the issue with other programmers?

Best regards, Diego

[james5]

Moving forward to the programmer set up, when the programmer gets disconnected,  the MCU  can wake up successfully at any time using LLWU_P4. Is that correct?

 When the MCU failed to wake up, did you had a debug session running? When entering VLLS, the debugger could experience a hang-up that alters posterior code execution.

I'm not sure where you got the idea that I was using the Cyclone as a debugger.   I have only done that once to read out the internal config registers right before going to sleep at the request of the local FAE.  I normally use the LPC-LINK2 for debugging.  It didn't have the facility to read out the 80-bit UID during the programming phase so we had to, at the suggestion of NXP, move to the PE Micro Cyclone for programming.

As clearly stated above, the first time the circuit runs with a battery attached and the Cyclone NOT providing power, it will run properly until it enters VLLS3.  At that point it will not wake up until I short nRST to GND.  Then it reboot and wakes up from VLLS3 as expected.  The debugger is NOT involved with this in any way.

Using the same image, if I program the circuit without a battery attached and the Cyclone providing power to program, then things work as expected.  This seems to be consistent because when power is applied after programming it will go through a full power-up reset sequence.

I have also confirmed that nRST is toggled a few times during the programming process with the PE Micro.  The final time being a low pulse of ~500uS.  I program via the command line so that it is done the same every time.

James

[diego_charles]

Hello james@stratforddigital.ca‌

Thank you so much for your taking the time to explain further! and sorry for my late reply.

Maybe simplifying the code could help us to find the issue.

• For example,  in the main function put the MCU in VLLS3 power mode, without using any of both paths,

and check if the  MCU is able to wake up, after programming using the battery, for example by printing messages on a serial terminal when before the wake-up and after. 

• Also, to have more elements to try to explain the issue, could you replace the battery with a power supply?

And test with the supply voltage equal to the battery voltage and the programmer voltage.

After checking the code that you posted seems ok. Did you

Use the SDK example power mode switch as a reference?

Please let me know your results or any inconvenience.

Best regards Diego.

[james5]

Hi Diego,

Yes, I haven't mentioned it, but I am currently powering the circuit with a lab power supply at 3.0V and the issue remains.  So it doesn't seem to be related to just a battery issue of some sort.  It also happened with old batteries and new batteries.  I tried adjusting the power supply so that the MCU voltage was slightly above or slightly below the Cyclone 3.3V on its SWD interface.   None of that seemed to make any difference.

We do have a buzzer in the system, so in the past I have activated the buzzer just before and after the transition into VLLS3.  The circuit always boots OK and runs fine up to the point where it is instructed to go into VLLS3 mode.  The issue is that the first time after programming with the Cyclone that it won't wake up properly.

The one thing I'll check in the morning is if the MCU gets into VLLS3 in this error condition.  I do know that when operating properly the current consumed is very low (~5uA).  But I guess I don't know 100% if that is the case in this error condition.

As for power supply, the micro runs directly off of the battery, there is no SMPS in the path.

It seems that there is a bit or setting somewhere that isn't being reset properly somehow.  Either one of 3 things is happening:

1) the MCU isn't getting into VLLS3 properly (I'll measure current draw to confirm this)

2) the MCU has somehow gated the interrupt that allows it to wakeup

3) the MCU tries to wakeup and can't for some reason

If the MCU goes through a full power up or a hard-short from nRST to GND then it behaves as expected.  There has to be something here.  Are there any undocumented settings or control bits that might be effecting this?

What would an interrupt flag that was set but not cleared do?  I don't think I have any interrupts enabled so that shouldn't be an issue.  I only asked because of the errata on the part about the RTC flag being set causing an issue with getting into low-power mode.  Is there anything else to that errata that isn't published that I might be hitting?

The code is actually pretty simple (though I can't post it).  If it wakes up, assuming the button was pressed long enough, then it does some calculations, sets some I/O, and then goes right back to sleep.  If it wakes up and the button hasn't been pressed long enough then it goes right back to sleep without doing anything else.

I know it is strange times and everyone is doing their best, but if we could get a little faster than 5-day turnaround on messages it would be appreciated.  This issue is gating us from releasing to production.

James.

[james5]

I was able to measure the current and confirm that the device is indeed getting to VLLS3 after the Cyclone programmer releases the reset.  I also added some audio tones on power-up and just before it goes into deep sleep due to button not being pressed (which is typically the case after programming).   I confirmed that the code does go through that path by hearing both audio tones.  So we seem to get into VLLS3 OK.

I also confirmed that when I press the button (connected to LLWU pin 4) the current increases.  So the device exits VLLS3.  But the first audio tone, right after the init code, does NOT sound.  So the code gets stuck somewhere.

I sent the startup code to Derrick.  I'll ask him to forward it to you.  I would rather not post that publicly.

So what here could get stuck?  There isn't much.

James.

[james5]

More info...

You should see some code fragments from FAE Derrick which will help explain things.  Please don't post that code publicly...

So I confirmed that NO CODE is being run after the first time asleep.  First line of code is BoardInitPins().  The I added 4 lines to set one of the I/O lines HIGH, LOW, HIGH, LOW and used an oscilloscope to monitor.  During normal operation, I see the GPIO line toggle as expected.  But when trying to wake from the first VLLS3 state, the GPIO DOESN'T TOGGLE.  So no code is running properly.

So here is the problematic path for convenience:

- program image and flash data into MCU with PE Micro Cyclone

- enable reset for 250ms and then release

- code starts to run, detects button is not pressed, and then goes into VLLS3 power mode with confirmed current draw of ~3-5uA (after removing SWD cable to Cyclone)

- button is pressed, more current is drawn (~1mA), but GPIO does not toggle.

If I short nRST to GND then the code restarts and I see the GPIO toggle (and audio tone sound as expected) on every wakeup with the button press.

So that nails it down quite a bit and seems to point to something to do with the IRQ.

James

[james5]

A couple of clarifications:

1)  The code to toggle the GPIO are after Board_InitPins() AND PMC_ClearPeriphIsolationFlag() functions.  Nothing else is before the GPIO toggle code.

2)  The first boot after the Cyclone releases reset functions as expected:  I see the GPIO toggle and hear the audio tones as expected.  The issue, as it always has been, is restarting from the first time the device enters VLLS3.

James.

[diego_charles]

Hi James Morrison‌,

Thank you for your additional information!

After checking the code that you send me, I got a more clear idea of your procedure.

I´ve received feedback on the case. What could be happening is that after the part is flashed, it still has debug active. So when you try to put the MCU into VLLS3, it is not actually entering that mode. Therefore the LLWU pin cannot wake up the part if it is not in a low leakage state. After a reset, then the part is likely not in a debug state that prevents the VLLS entry. 

I  managed to replicate the issue with an FRDM-KL03 flashing the SDK example power mode switch, with a modification to put the MCU into VLLS3 directly. In the same way, after flashing and trying to set the MCU into VLLS3, the LLWU_P4 does not provocate a reset and the LLWU_IRQHandler is not executed. As you mention, a power cycle or a reset makes the device operate as expected.

As soon  I get more useful information I´ll let you know!

Best regards, Diego.

[james5]

Any update on this diego.charles‌?

[diego_charles]

Hello,  james@stratforddigital.ca‌

Yes, I´ve an update.

Sorry for the delay, I had to check with my colleagues about the issue. 

I have to mention that when I replicated the issue (with the FRDM-KL03 ) the onboard debug probe had the PE micro firmware.

When I updated the firmware for CMSIS-DAP or  Segger JLINK the MCU was able to wake up after programming, just as expected. 

The root of the issue could be the way that the PE Cyclone takes out the MCU from the debug state, which is enabled even for programming. 

By now I can recommend you check if the problem still arises using another programmer for production.

My best wishes!

Diego.

[james5]

Hello diego.charles‌,

The Cyclone PE Micro has already been selected as the production programming tool, at the suggestion of NXP directly.  So changing it is not an option at this point as we've already committed to it and have invested into that infrastructure.

Please suggest some code I can add at the beginning of my code to ensure that the debug mode has been exited properly.  Remember, the code always runs until the first sleep.  If I can execute some code to ensure that we have exited debug mode properly then things should work fine.

James.

[james5]

Hi Diego, that sounds promising.  Please note that when the code does put the micro to sleep for the first time, I do measure current consumption that is about equal to what I measure when I  know it's in VLLS mode.  I can't say for sure if it's actually getting into the mode, but I can say that the current consumption sure looks like it.

But it does sound like we're poking in the right area now.  Please do let me know any more details.

James.