AnsweredAssumed Answered

MKW41Z SOC is resetting continuously reason as core Lockup, when toggling between VLPS and Run modes continuously

Question asked by Yuvaraj Nagendran on Nov 15, 2017
Latest reply on Nov 27, 2017 by Gerardo Rodríguez

Like • Show 0 Likes0
Comment • 3

Hi,

We are trying to port our application which was running on MSP430 and CC2520 Radio with single MKW41Z512 SoC from NXP. I am using TPM0 timer clocked with MCGIRCLK at 4MHz fast IRC to wake up from VLPS (Very Low Power Stop) mode. I am also using TPM1 and TPM2 for some other purpose to come out of sleep mode. I am entering into VLPS mode directly from RUN mode (FEE) and exiting back to RUN mode with these timers. The SOC resets itself with Core Lockup bit set in RCM_SRS1 register. This issue is not happening when running the same with debugger (which I think doesn't stop the MCG clock to enable debugging). If the VLPS mode enter is removed then there is no reset.

I have used the driver example to enter to VLPS mode.

status_t SMC_SetPowerModeVlps(SMC_Type *base)
{
uint8_t reg;

    /* configure VLPS mode */
    reg = base->PMCTRL;
    reg &= ~SMC_PMCTRL_STOPM_MASK;
    reg |= (kSMC_StopVlps << SMC_PMCTRL_STOPM_SHIFT);
    base->PMCTRL = reg;

/* Set the SLEEPDEEP bit to enable deep sleep mode */
SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;

    /* read back to make sure the configuration valid before enter stop mode */
    (void)base->PMCTRL;
    __DSB();
    __WFI();
    __ISB();

    /* check whether the power mode enter VLPS mode succeed */
    if (base->PMCTRL & SMC_PMCTRL_STOPA_MASK)
    {
        return kStatus_SMC_StopAbort;
    }
    else
    {
        return kStatus_Success;
    }
}

One another point to add up is that only once in 3 times this code returns kStatus_Success and most of the other times it returns kStatus_SMC_StopAbort, for which also I couldn't find a reason.

Any quick help or suggestion will be greatly appreciated as we need to solve this to take a decision on using this SoC as power consumption is very stringent requirement.

No one else has this question

Outcomes

Gerardo Rodríguez

Nov 21, 2017 1:55 PM

Hello Yuvaraj Nagendran,

The MCU can’t enter to VLPS while debugging is enabled and instead enters STOP mode. You can refer to chapter 9.6 Debug in Low Power Modes in the reference manual for more information on this.

Regarding, the core lockup. Can you give more details of when it occurs? Does it happen when entering or exiting VLPS?

Can you share what demo application are you using and what modifications were made? For example, the power mode switch demo can be used to enter VLPS and configure the wake up source with a button or the LPTMR.

Additionally, what wireless protocol stack will you be using? I ask this because most of the wireless examples can be configured to go to low power modes and it is all managed automatically by the low power library.

Regards,

Actions

Yuvaraj Nagendran Nov 22, 2017 12:03 AM

Hi Rodriguez,

Thanks a lot for the response.

We have a firmware application which requires 2 independent timers for its operation in VLPS mode. I am using LPTMR clocked with ERCLK32K (external 32 KHz TCXO) and TPM0 which is clocked with MCGIRCLK. To make the MCGIRCLK to work in both VLPS and Run mode I have configured the MCGIRCLK with Fast IRC 4 MHz clock (MCG_C2[1] = 1, MCG_C1[IRCLKEN]) = 1 and MCG_C1[IREFSTEN] = 1) and enabled it to work in VLPS mode.

The SOC is expected to remain in VLPS mode and needs to come out of sleep with LPTMR interrupt or TMP0 interrupt or a GPIO interrupt. But the SOC is getting reset continuously, reason being core lockup. The core Lockup doesn’t happen if we don’t start the LPTMR. We also do some PHY related Rx and Tx operations in this LPTMR handler.

By further drilling down we found the reason for the core lockup as well. When we exit from the VLPS mode using LPTMR handler we try accessing the phy related ZLL registers which is causing this lock up. If we don’t access that we are not getting into lockup. We added around 100 microsecond delay and it started working. But still if we run it overnight we are seeing restarts because of Core lockup.. Can you please help us from here why there is a core lockup if we access phy ZLL registers after waking up from sleep mode and what can be done to make this work without delays ?

We are using ZigBee 802.15.4 wireless communication.

Regards,

Yuvi.

Actions

Gerardo Rodríguez

@ Yuvaraj Nagendran on Nov 27, 2017 3:54 PM

Hello Yuvi,

I think your issue could be related to accessing the ZLL registers before the RF Reference Oscillator is ready. I highly recommend basing your application on one of our demo applications such as the SMAC low power node and see how the power modes are managed.

Additionally, ZigBee 3.0 will be supported in KW41Z in Q1 2018.

Regards,

Actions

3 Replies

Gerardo Rodríguez Nov 21, 2017 1:55 PM
Mark Correct
Correct Answer
Hello Yuvaraj Nagendran,

The MCU can’t enter to VLPS while debugging is enabled and instead enters STOP mode. You can refer to chapter 9.6 Debug in Low Power Modes in the reference manual for more information on this.

Regarding, the core lockup. Can you give more details of when it occurs? Does it happen when entering or exiting VLPS?

Can you share what demo application are you using and what modifications were made? For example, the power mode switch demo can be used to enter VLPS and configure the wake up source with a button or the LPTMR.

Additionally, what wireless protocol stack will you be using? I ask this because most of the wireless examples can be configured to go to low power modes and it is all managed automatically by the low power library.

Regards,
Like • Show 0 Likes0
Actions
Yuvaraj Nagendran Nov 22, 2017 12:03 AM
Mark Correct
Correct Answer
Hi Rodriguez,
Thanks a lot for the response.

We have a firmware application which requires 2 independent timers for its operation in VLPS mode. I am using LPTMR clocked with ERCLK32K (external 32 KHz TCXO) and TPM0 which is clocked with MCGIRCLK. To make the MCGIRCLK to work in both VLPS and Run mode I have configured the MCGIRCLK with Fast IRC 4 MHz clock (MCG_C2[1] = 1, MCG_C1[IRCLKEN]) = 1 and MCG_C1[IREFSTEN] = 1) and enabled it to work in VLPS mode.
The SOC is expected to remain in VLPS mode and needs to come out of sleep with LPTMR interrupt or TMP0 interrupt or a GPIO interrupt. But the SOC is getting reset continuously, reason being core lockup. The core Lockup doesn’t happen if we don’t start the LPTMR. We also do some PHY related Rx and Tx operations in this LPTMR handler.
By further drilling down we found the reason for the core lockup as well. When we exit from the VLPS mode using LPTMR handler we try accessing the phy related ZLL registers which is causing this lock up. If we don’t access that we are not getting into lockup. We added around 100 microsecond delay and it started working. But still if we run it overnight we are seeing restarts because of Core lockup.. Can you please help us from here why there is a core lockup if we access phy ZLL registers after waking up from sleep mode and what can be done to make this work without delays ?

We are using ZigBee 802.15.4 wireless communication.

Regards,
Yuvi.
Like • Show 0 Likes0
Actions
- Gerardo Rodríguez @ Yuvaraj Nagendran on Nov 27, 2017 3:54 PM
  Mark Correct
  Correct Answer
  Hello Yuvi,
  
  I think your issue could be related to accessing the ZLL registers before the RF Reference Oscillator is ready. I highly recommend basing your application on one of our demo applications such as the SMAC low power node and see how the power modes are managed.
  
  Additionally, ZigBee 3.0 will be supported in KW41Z in Q1 2018.
  
  Regards,
  Like • Show 0 Likes0
  Actions

MKW41Z SOC is resetting continuously reason as core Lockup, when toggling between VLPS and Run modes continuously

Outcomes

Related Content

Recommended Content