Waking up from deep-sleep with timer32/WDTOSC

[lpcware]

Content originally posted in LPCWare by ktownsend on Fri Mar 26 10:58:30 MST 2010
I've been trying to write some generic code to enter deep sleep mode with the LPC1114 (easy enough), and then wakeup after a fixed number of seconds using 32-bit timer 0 off WDTOSC.

Entering deep sleep is fine, but it I haven't been able to get the device to wakeup using the timer, and I'm really starting to scratch my head on this.

My apologies if the code below is partial, but I'm using a header file I wrote myself since I hate having magic-numbers everywhere [reg1 = 0xA033F300] ... it should be clear with the names what values are being set, though.

The methods below are used with the following test code in main:

    U32 pmuRegVal;
 
    // Configure wakeup sources before going into sleep/deep-sleep.
    // By default, pin 0.1 is configured as wakeup source (falling edge)
    pmuInit();
 
    // Put peripherals into sleep mode (leave WDTOSC enabled)
    pmuRegVal = SCB_PDSLEEPCFG_IRCOUT_PD |
                SCB_PDSLEEPCFG_IRC_PD |
                SCB_PDSLEEPCFG_FLASH_PD |
                SCB_PDSLEEPCFG_BOD_PD |
                SCB_PDSLEEPCFG_ADC_PD |
                SCB_PDSLEEPCFG_SYSPLL_PD;
 
    // Enter deep sleep mode (wakeup after 5 seconds)
    pmuDeepSleep(pmuRegVal, 5);

It's a long read, but here are the key methods if someone is brave enough to look through them. If there are any clear examples of waking up from deep sleep on a timer capture that would be useful as well.

Kevin.

 
/**************************************************************************/
/*! 
    \brief Initialises the power management unit
    Initialise the power management unit, and configure pin 0.1 to act as
    a wakeup source from sleep or deep-sleep mode.
    For sleep and deep-sleep modes, entered via pmuSleep(), P0.0..11 and
    P1.0 can be used as a wakeup source.  For deep power-down mode, entered
    via pmuPowerDown(), only a low level on pin 1.4 (WAKEUP) can wake the
    device up.
*/
/**************************************************************************/
void pmuInit( void )
{
  /* Enable all clocks, even those turned off at power up. */
  SCB_PDRUNCFG &= ~(SCB_PDRUNCFG_WDTOSC_MASK | 
                    SCB_PDRUNCFG_SYSOSC_MASK | 
                    SCB_PDRUNCFG_ADC_MASK);
  /* Enable wakeup interrupts (P0.1..11 and P1.0 can be used) */
  NVIC_EnableIRQ(WAKEUP1_IRQn);      // P0.1
  /* Configure pin 0.1 as wakeup source (MAT2 on 32-bit Timer 0) */
  IOCON_PIO0_1 &= ~IOCON_PIO0_1_FUNC_MASK;
  IOCON_PIO0_1 |= (IOCON_PIO0_1_FUNC_GPIO |
                   IOCON_PIO0_1_HYS_ENABLE);
  /* Set pins to input for wakeup */
  gpioSetDir( 0, 1, gpioDirection_Input );
  /* Only edge trigger. activation polarity on P0.1 is FALLING EDGE. */
  SCB_STARTAPRP0 = ~SCB_STARTAPRP0_MASK;      // ~0xFFFFFFFF;
  /* Clear all wakeup source */ 
  SCB_STARTRSRP0CLR = SCB_STARTRSRP0CLR_MASK;
  /* Enable Port 0.1 as wakeup source. */
  SCB_STARTERP0 |= SCB_STARTERP0_ERPIO0_1;
  return;
}
/**************************************************************************/
/*! 
    Setup the clock for the watchdog timer.  The default setting is 10kHz.
*/
/**************************************************************************/
static void pmuWDTClockInit (void)
{
  /* Configure watchdog clock */
  /* Freq. = 0.5MHz, div = 50: WDT_OSC = 10kHz  */
  SCB_WDTOSCCTRL = SCB_WDTOSCCTRL_FREQSEL_0_5MHZ | 
                   SCB_WDTOSCCTRL_DIVSEL_DIV50;
  /* Set clock source (use external crystal) */
  SCB_WDTCLKSEL = SCB_WDTCLKSEL_SOURCE_INPUTCLOCK;
  SCB_WDTCLKUEN = SCB_WDTCLKUEN_UPDATE;
  SCB_WDTCLKUEN = SCB_WDTCLKUEN_DISABLE;
  SCB_WDTCLKUEN = SCB_WDTCLKUEN_UPDATE;
  /* Wait until updated */
  while (!(SCB_WDTCLKUEN & SCB_WDTCLKUEN_UPDATE));
  /* Set divider */
  SCB_WDTCLKDIV = SCB_WDTCLKDIV_DIV1;
  /* Enable WDT clock */
  SCB_PDRUNCFG &= ~(SCB_PDRUNCFG_WDTOSC);
  // Switch main clock to WDT output
  SCB_MAINCLKSEL = SCB_MAINCLKSEL_SOURCE_WDTOSC;
  SCB_MAINCLKUEN = SCB_MAINCLKUEN_UPDATE;       // Update clock source
  SCB_MAINCLKUEN = SCB_MAINCLKUEN_DISABLE;      // Toggle update register once
  SCB_MAINCLKUEN = SCB_MAINCLKUEN_UPDATE;
  // Wait until the clock is updated
  while (!(SCB_MAINCLKUEN & SCB_MAINCLKUEN_UPDATE));
}
/**************************************************************************/
/*! 
    \brief  Turns off select peripherals and puts the device in deep-sleep
            mode.
    This function will put the device into deep-sleep mode.  Most gpio
    pins can be used to wake the device up, but the pins must first be
    configured for this in pmuInit.  By default, only pin 0.1 (ISP) is
    configured as a wakeup source.
    The device can be configured to wakeup from deep-sleep mode after a
    specified delay with the wakeupSeconds parameter.  This will configure
    32-bit timer 0 to set a match on pin 0.1 (ISP), which will wakeup
    the device up.  The timer will be configured to run off the WDT OSC
    while in deep-sleep mode, meaning that WDTOSC should not be powered
    off (using the sleepCtrl parameter) when a wakeup delay is specified.
    The sleepCtrl parameter is used to indicate which peripherals should
    be put in sleep mode (see the SCB_PDSLEEPCFG register for details).
 
    @param[in]  sleepCtrl  
                The bits to set in the SCB_PDSLEEPCFG register.  This
                controls which peripherals will be put in sleep mode.
    @param[in]  wakeupSeconds
                The number of seconds to wait until the device will
                wakeup.  If you do not wish to wakeup after a specific
                delay, enter a value of 0.
*/
/**************************************************************************/
void pmuDeepSleep(U32 sleepCtrl, U32 wakeupSeconds)
{
  SCB_PDAWAKECFG = SCB_PDRUNCFG;
  sleepCtrl &= ~(1 << 9);               // MAIN_REGUL_PD
  sleepCtrl |= (1 << 11) | (1 << 12);   // LP_REGUL_PD
  SCB_PDSLEEPCFG = sleepCtrl;
  SCB_SCR |= SCB_SCR_SLEEPDEEP;
  /* Configure system to run from WDT and set TMR32B0 for wakeup          */
  if (wakeupSeconds > 0)
  {
    // Make sure WDTOSC isn't disabled in PDSLEEPCFG
    SCB_PDSLEEPCFG &= ~(SCB_PDSLEEPCFG_WDTOSC_PD);
    // Disable 32-bit timer 0 if currently in use
    timer32Disable(0);
    // Reconfigure clock to run from WDTOSC
    pmuWDTClockInit();
    /* Enable the clock for CT32B0 */
    SCB_SYSAHBCLKCTRL |= (SCB_SYSAHBCLKCTRL_CT32B0);
 
    /* Configure PIO0.1 as Timer0_32 MAT2 */
    IOCON_PIO0_1 &= ~IOCON_PIO0_1_FUNC_MASK;
    IOCON_PIO0_1 |= IOCON_PIO0_1_FUNC_CT32B0_MAT2;
    /* Set appropriate timer delay */
    TMR_TMR32B0MR0 = PMU_WDTCLOCKSPEED_HZ * wakeupSeconds;
 
    /* Configure match control register to raise an interrupt and reset on MR0 */
    TMR_TMR32B0MCR = (TMR_TMR32B0MCR_MR0_INT_ENABLED | TMR_TMR32B0MCR_MR0_RESET_ENABLED);
 
    /* Configure external match register */
    TMR_TMR32B0EMR &= ~(0xFF<<4);                   // Clear EMR config bits
    TMR_TMR32B0EMR |= TMR_TMR32B0EMR_EMC2_TOGGLE;   // MR2 (GPIO0.1) Toggle
 
    /* Enable the TIMER0 interrupt */
    NVIC_EnableIRQ(TIMER_32_0_IRQn);
 
    /* Start the timer */
    TMR_TMR32B0TCR = TMR_TMR32B0TCR_COUNTERENABLE_ENABLED;
  }
  // Send Wait For Interrupt command
  __asm volatile ("WFI");
  return;
}

[lpcware]

Content originally posted in LPCWare by mstroven on Thu Aug 05 10:46:46 MST 2010
@Kevin
Thanks for the great code!  I am using the IAR compiler and the CMSIS core library.  I believe I have done the right mods to do a 5 second "deep sleep" with a wake on P0.1 as in your example.  Main difference for me is that my board has an external pullup on P0.1, so I am using negative edge triggering for the start logic.  Unfortunately, I have two problems:
1)  I can't debug using my Segger J-Link through a clock source transition.
2)  The board does not seem to wake...
Can you confirm that the edge selection in the start logic should not matter?

[lpcware]

Content originally posted in LPCWare by hfischer on Thu May 06 00:37:07 MST 2010
Hello Kevin,

sorry that it lasted that time but now I can confirm that your one pin solution with the lpc1114 will bring down the consumption to 11,8micro ampere. I will see what consumption i will achieve with my own layout :)
For this moment i thank you again for sharing the one-pin loopback solution :)

So what I have running is the WDTOSC and the TIMER16_0, with M0 on Pin0_8. Clocked with the lowest analog frequency and the highest possible digital clock divider.
I do not use timer32 cause I wondered if there is more consumption by this peripheries but this was not the point. Now I use timer16_0 cause its free for it :)

Regards

[lpcware]

Content originally posted in LPCWare by johnhe on Wed Apr 21 06:44:44 MST 2010
Hi Hfischer

Your statements are puzzzling. There is nothing abnormal about using 8mA (milli-amps) with the LPC1114. It simply means you are not entering or staying in deep sleep, or you drawing power unexpectedly, such as through pins.

If you go into deep sleep as recommended and set up the pins appropriately you can expect to use six uA (micro-amps) with the LPC1114.

If you leave the watchdog oscillator on in deep sleep and allow it to clock a timer peripeheral then you can expect to use an additional few uA.

I have code posted on this thread for the LPC1343 that added five uA to the rated deep sleep current of 30 uA for the LPC1343.

I have code on another thread, http://knowledgebase.nxp.com/showthread.php?t=187, that achieved six uA for the LPC1114 in deep sleep.

John Heenan

---

Quote: hfischer
Hi John,

this is not my problem ;)

I think through some electrical influences on the board I generate while do measurement or editing the hardware, the MCU is not that current saving as tested before.
It only goes down to 8mA and not to 11microAmp.

Will see if I put again a new one on the board :P

Regards

---

[lpcware]

Content originally posted in LPCWare by hfischer on Wed Apr 21 06:11:56 MST 2010
Hi John,

this is not my problem ;)

I think through some electrical influences on the board I generate while do measurement or editing the hardware, the MCU is not that current saving as tested before.
It only goes down to 8mA and not to 11microAmp.

Will see if I put again a new one on the board :P

Regards

[lpcware]

Content originally posted in LPCWare by johnhe on Wed Apr 21 02:37:03 MST 2010
If you have locked yourself out of the LPC1114 LPCXpresso board you may have no other choice than to use ISP to erase the current program.

Erasing with Flash Magic, http://www.flashmagictool.com/ , works fine with direct connections to cheap USB-UART converters. No extra electronics are required.

I use a DLP-2232M board with four wires to RXD, TXD, FT/GPIO and RST pins on the LPCXpresso board from D0, D1, D2 and D4 respectively on the DLP-2232M. For the LPC1343 LPCXpresso board it is also necessary to ground the USB-VBUS pin.

John Heenan

---

Quote: hfischer

the 11-8microAmp solution was with the wdt clock, analog set to 500kHz and dividing it by every divisor to come down to 7,8kHz with attention to the deviation. But i used timer16_1 for this way of loop back wake up.

I measured on lpcexpresso board with an lpc1114 with every connector to the jtag interface cut off. I supplied the lpc1114 unit with a voltage supply and measures the current serial.
At the moment I'm not in the position to do some new power down test, and i think I have crashed the MCU again with some electrostatics :rolleyes: because the old programm just gets 8mA which is not comprehensible.
I'll take another trial in time.

Regards

---

[lpcware]

Content originally posted in LPCWare by hfischer on Wed Apr 21 01:48:02 MST 2010
Hi Kevin,

the 11-8microAmp solution was with the wdt clock, analog set to 500kHz and dividing it by every divisor to come down to 7,8kHz with attention to the deviation. But i used timer16_1 for this way of loop back wake up.

I measured on lpcexpresso board with an lpc1114 with every connector to the jtag interface cut off. I supplied the lpc1114 unit with a voltage supply and measures the current serial.
At the moment I'm not in the position to do some new power down test, and i think I have crashed the MCU again with some electrostatics :rolleyes: because the old programm just gets 8mA which is not comprehensible.
I'll take another trial in time.

Regards

[lpcware]

Content originally posted in LPCWare by ktownsend on Tue Apr 20 05:31:50 MST 2010

---

Quote: hfischer
Hi Kevin,
Looking forward for good discussions, Kevin :)

---

In regards to the 8-11uA you were getting previously, I removed a few components from my board (such as a supervisor that was consuming 30uA, ouch) and am able to get to around 30uA with the voltage regulator (ADP121 consuming about 13uA), EEPROM (~2uA inactive), and keeping the WDTOSC and 32-Bit TIMER active.  I might be able to save a couple more uA optimising the HW, but 30uA total will already give me more than 2 years at a 300:1 duty cycle, which is fine for me.  I can probably even run it from a small solar cell and a couple supercaps in series, but I'll need to try it in practice first.

I was just wondering, though, if that 8/11uA figure was with the WDTOSC + TIMER enabled in deep sleep, or with them shut off?  I'll have to pick up an 1114 LPCXpresso board myself just to compare.

[lpcware]

Content originally posted in LPCWare by johnhe on Tue Apr 20 01:51:33 MST 2010
Hi Hfischer

Yes, we do need a proper clarification or correction from NXP.

There are various reasons to leave an oscillator running in sleep

1) To allow fast reuse the oscillator and its associated functionality on wakeup, by not having to wait for the oscillatoe to start up.
2) To allow a peripheral to remain running in sleep.

Normal sleep only stops the clock to the core.

Deep sleep stops the clock to the NVIC.

It is up to the ARM chip vendor as to what they may or may not also allow in deep sleep with configuration.

Currently there is a factual difference between what the manual says we can do and what we can in fact do.

NXP is only obliged to support and to keep to what the manual says can be done.  There is no obligation by NXP to keep providing devices that include current undocumented functionality.

We should not draw inferences that are not backed up by explicit statements. There are so many issues we cannot possibly be in a position to be aware of.

John  Heenan

---

Quote: hfischer
Hi John,

thanks for your answer but I will wait for a reliable answer from NXP Staff, because it could also be that the manual has an error. I dont want to ignore your point of view, maybe there are some reasons why NXP will not be able to make SW wakeup from deepsleep, but it is speculating about unknown structures.

As you mentioned some positions in the manual, you cannot ignore the faults where the manual contradict.
Why should the OSC will be left running if they would never take effect, only for the wdt and clockout peripherie?

But I think if this is right a fault in the silicon scemetics, there will be a way by peridiocal wakeup the MCU by the Clockout peripherie, which is fed by his own selected osc.

Maybe an NXP staff could probably give some further information, because an fault between documentation, manual and hardware is indisputable.

Thanks and regards

---

[lpcware]

Content originally posted in LPCWare by hfischer on Tue Apr 20 01:40:43 MST 2010
Hi Kevin,

I am waiting eagerly on this mail :)
After reading the manual again and again I searched for new version, but found a new version of the datasheet not the user manual, but there, the deepsleep functional requirements are summarized, as we found out it will be in hardware.

Here the new note about sleep and deep sleep from the datsheet from the 16th of April this year.

---

Quote:

7.15.5.1 Sleep mode
When Sleep mode is entered, the clock to the core is stopped. Resumption from the Sleep
mode does not need any special sequence but re-enabling the clock to the ARM core.
In Sleep mode, execution of instructions is suspended until either a reset or interrupt
occurs. Peripheral functions continue operation during Sleep mode and may generate
interrupts to cause the processor to resume execution. Sleep mode eliminates dynamic
power used by the processor itself, memory systems and related controllers, and internal
buses.
7.15.5.2 Deep-sleep mode
In Deep-sleep mode, the chip is in Sleep mode, and in addition analog blocks can be shut
down for increased power savings. The user can configure the Deep-sleep mode to a
large extent, selecting any of the oscillators, the PLL, BOD, the ADC, and the flash to be
shut down or remain powered during Deep-sleep mode. The user can also select which of
the oscillators and analog blocks will be powered up after the chip exits from Deep-sleep
mode.
The GPIO pins (up to 15 pins total) serve as external wake-up pins to a dedicated start
logic to wake up the chip from Deep-sleep mode.
The timing of the wake-up process from Deep-sleep mode depends on which blocks are
selected to be powered down during deep-sleep.
For lowest power consumption, the clock source should be switched to IRC before
entering Deep-sleep mode, all oscillators and the PLL should be turned off during
deep-sleep, and the IRC should be selected as clock source when the chip wakes up from
deep-sleep. The IRC can be switched on and off glitch-free and provides a clean clock
signal after start-up.
If power consumption is not a concern, any of the oscillators and/or the PLL can be left
running in Deep-sleep mode to obtain short wake-up times when waking up from
deep-sleep.

---

Looking forward for good discussions, Kevin :)

Thanks and regards.

[lpcware]

Content originally posted in LPCWare by ktownsend on Tue Apr 20 01:32:48 MST 2010

---

Quote: hfischer
Maybe an NXP staff could probably give some further information, because an fault between documentation, manual and hardware is indisputable.

---

I sent an email to NXP, so hopefully that can clear the issue up whether the feature will remain in future revision, and brought this thread to their attention as well.  It's true the documentation isn't always that helpful where deep sleep and the other low power modes is concerned.  I'm sure they'll improve it in the future, though.

[lpcware]

Content originally posted in LPCWare by johnhe on Tue Apr 20 01:28:39 MST 2010
You have nothing to say except to heap abuse on me.

You clearly cannot take the heat. Really amateurish. Point proven.

John Heenan

---

Quote: KTownsend
Wow.  Are you as belligerent as this in real life as well? :D

I come here to help other people as best I can, and post some questions myself.  If my methodology isn't up to your extremely exacting standards (that even you don't meet judging by your past flawed posts), feel free to ignore them.  If you want to analyse them to the nth degree, great ... I made some changes thanks to that ... but don't expect everyone to jump through your hoops to please you or your exacting standards.  Your own code is clearly flawed as well (there is no point enabling the timer interrupt since it won't fire from deepsleep ... the wakeup interrupt and configuring the timer MAT is what matters).  NXP can probably clarify the issue (they've already made comments on this forum to this effect), and I'll bring it to their attention.

I'm confident the feature will stay, but only NXP can really clear that up.  Just a tip, though ... people might take you a bit more seriously as well if you were a bit less bellegerent after constantly insulting the NXP support staff, NXP, and anyone who disagrees with you or suggest you might possible be mistaken as well.  It's hardly a great way to convince people to spend the time and effort of answering your own questions, etc.

---

[lpcware]

Content originally posted in LPCWare by hfischer on Tue Apr 20 01:21:28 MST 2010
Hi John,

thanks for your answer but I will wait for a reliable answer from NXP Staff, because it could also be that the manual has an error. I dont want to ignore your point of view, maybe there are some reasons why NXP will not be able to make SW wakeup from deepsleep, but it is speculating about unknown structures.

As you mentioned some positions in the manual, you cannot ignore the faults where the manual contradict.

---

Quote:

3.7 Power management
...
In Deep-sleep
mode, the user can configure the remaining power-consumption to a large extend by
selecting various analog blocks as well as the flash and the oscillators to remain powered
or to be shut down.
...

---

Why should the OSC will be left running if they would never take effect, only for the wdt and clockout peripherie?

But I think if this is right a fault in the silicon scemetics, there will be a way by peridiocal wakeup the MCU by the Clockout peripherie, which is fed by his own selected osc.

Maybe an NXP staff could probably give some further information, because an fault between documentation, manual and hardware is indisputable.

Thanks and regards

[lpcware]

Content originally posted in LPCWare by ktownsend on Tue Apr 20 01:19:41 MST 2010

---

Quote: johnhe
Seriously, you are really naive expecting us to take your statement seriously. You have also seriously exposed NXP to be really amateurish (as well as yourself).

---

Wow. Are you as belligerent as this in real life as well? :D

I come here to help other people as best I can, and post some questions myself. If my methodology isn't up to your extremely exacting standards (that even you don't meet judging by your past flawed posts), feel free to ignore them. If you want to analyse them to the nth degree, great ... I made some changes thanks to that ... but don't expect everyone to jump through your hoops to please you or your exacting standards. Your own code is clearly flawed as well (there is no point enabling the timer interrupt since it won't fire from deepsleep ... the wakeup interrupt and configuring the timer MAT is what matters). NXP can probably clarify the issue (they've already made comments on this forum to this effect), and I'll bring it to their attention.

I'm confident the feature will stay, but only NXP can really clear that up. Just a tip, though ... people might take you a bit more seriously as well if you were a bit less belligerent after insulting the NXP support staff, NXP, and anyone who disagrees with you or suggest you might possible be mistaken as well. It's hardly a great way to convince people to spend the time and effort of answering your own questions, etc.

[lpcware]

Content originally posted in LPCWare by johnhe on Tue Apr 20 00:57:19 MST 2010
I have looked at the deep sleep architecture for the ARM Cortex series. From memory, I think the main obligatory requirement on vendors with deep sleep is to shut off the clock to the NVIC interrupt controller. This will prevent interrupts being triggered from normal peripherals. With normal sleep just the clock to the core is shut off.

So I don't think NXP are violating architectural standardsby allowing peripeherals to be clocked during deep sleep: the NVIC simply will not be able to notice their interrupts. NXP allows what they vaguely call 'start logic' to trigger a device to leave deep sleep, using pins.

With this in mind we are then at the mercy of ARM vendors, such as NXP, as to what they choose to allow clocks to do with peripherals during deep sleep. The manual is pretty clear in this case. The system clock is disabled. The system clock clocks peripherals. We now know this is not true.

Despite what NXP staff are said to be saying, I suspect the clocking of peripherals is really a silicon fault instead of intentional. ARM chip implementations have always been weak on low power issues and on clocking in low power, I imagine for territorial patent reasons

What I imagine happened is that there was a design review failure that failed to notice design features that should have been removed, as patent licenses are unlikely to has been obtained for the features.

On the other hand they could be a forgotten feature from a time when NXP was expected to be bought out by a competitor who perhaps has licenses for the features. I think the markets have got tired of using NXP for their favourite imminent takeover target whipping boy.

There is no mercy in the ruthless cut throat silicon industry, which is held precariously intact by the threat of mutually assured destruction if patent violation wars break out and by keeping to territorial patches.

Unless there are explicit statements from NXP that corrects the manual, we cannot assume the peripheral clocking in deep sleep can be configured to remain on during deep sleep.

On the other hand maybe NXP want to be taken over to escape their crippling debt, and are goading the industry! I would hate to think we are being manipulated as pawns.

This is what I stated earlier in this thread:

---

Quote: johnhe

   From the LPC111x user manual section 3.7.3:
  
   "In Deep-sleep mode (see Section 3–8) for details), the chip is in Sleep mode, the system clock is disabled,"
  
   So what is the system clock?
  
   From the LPC111x user manual section 3.4.11:
   
    "The main system clock clocks the core, the peripherals, and the memories."
  
  So in deep sleep, the clock is disabled higher up the hierarchy than for normal sleep. Normal sleep just disables the clock to the core. For sleep purposes the interrupt controller (NVIC) should be considered a peripheral and not part of the core. The interrupt controller also requires a clock. For deep sleep 'start logic' connected to pins provides a workaround to this requirement.
   
  Since the system clock is disabled in deep sleep there is a disconnect between a relevant oscillator that may not be shut down during deep sleep and between timer peripherals.
  
  While a timer peripheral will wake up from normal sleep, a timer peripheral cannot be used to wake up from deep sleep with the LPC1114, even if its oscillator is not shut down.
  
   There is no separate RTC domain for the LPC1114 to generate a start logic interrupt.
  

---

John Heenan

---

Quote: hfischer
Hi all,

maybe one of the NXP Staff or technical artist could give an answer to this odd circumstance. Cause me and I think other developer rely on the documents which are released. And when there is a feature which is not revealed in the documents, why should it not work.
I wonder if you, John, give us your source for your claim that it is a hardware fault in the silicon and it should not be relied on it, because my development bases on this possibility to wakeup by software from deep sleep.
If it would not be sure that this feature will be supported for long time, I have to think about a other solution, what would hurry out to a other producer of MCUs.

Thanks

---

[lpcware]

Content originally posted in LPCWare by johnhe on Tue Apr 20 00:09:25 MST 2010
I need to see a copy of the schematic for your board. You told us you are not using LPCXpresso boards.

John Heenan

---

Quote: KTownsend
I've just added the drvpins method to my code and call it before sending WFI .. it doesn't make any difference in the amount of current being drawn by my board in deep sleep.  It's still around 60uA.  I tried with both of these settings:

 
drvpins(0, 0, 0, 0, 0, 0, 0, 0);
drvpins(0xFFF, 0xFFF, 0xFFF, 0xFFF, 0xFFF, 0xFFF, 0x3F, 0x3F);

---

[lpcware]

Content originally posted in LPCWare by hfischer on Mon Apr 19 22:52:38 MST 2010
Hi all,

maybe one of the NXP Staff or technical artist could give an answer to this odd circumstance. Cause me and I think other developer rely on the documents which are released. And when there is a feature which is not revealed in the documents, why should it not work.
I wonder if you, John, give us your source for your claim that it is a hardware fault in the silicon and it should not be relied on it, because my development bases on this possibility to wakeup by software from deep sleep.
If it would not be sure that this feature will be supported for long time, I have to think about a other solution, what would hurry out to a other producer of MCUs.

Thanks

[lpcware]

Content originally posted in LPCWare by johnhe on Mon Apr 19 17:04:53 MST 2010
Seriously, you are really naive expecting us to take your statement seriously. You have also seriously exposed NXP to be really amateurish (as well as yourself).

The manual is black and white. The manual is contradicted.

We accept the LPC13xx and LPC11xx are very cheap parts with compromises, such as lack of a separate RTC domain that can be used to wake up a part form deep sleep. Of course such a feature as timer wakeup from deep sleep without a separate RTC domain is desired. TI with their MSP430 parts are very well known for having done an excellent job.

If NXP have experimentally added in an undocumented feature and chosen not to reveal it, what if they then decide to withdraw it in the future? What about market advantage NXP may be counting on?

What if the feature violates someone else patents, such as those of TI?

If what you say is true, then expect to now find yourself on a NXP blacklist as a foolish amateur, as well as those of just about every other silicon chip company, once this farce gets around.

John Heenan

---

Quote: KTownsend
[/FONT]
 
[FONT=Helvetica]Seriously ... it's intentional, NXP did it on purpose, they were the ones who brought it to my attention (thanks to their excellent and very competent technical support staff), and it makes perfect sense. What's the point of deep-sleep that you can't exit in SW?[/FONT]

---

[lpcware]

Content originally posted in LPCWare by rkiryanov on Mon Apr 19 11:54:42 MST 2010

---

Quote: KTownsend
What's the point of deep-sleep that you can't exit in SW?

---

During Deep-sleep mode, the [B]processor state and registers[/B], peripheral registers, and [B]internal SRAM values are maintained[/B]

During Deep power-down mode, the [B]contents of the SRAM are not retained[/B].

[lpcware]

Content originally posted in LPCWare by ktownsend on Mon Apr 19 10:14:17 MST 2010

---

Quote: johnhe
[FONT=Helvetica, Arial, sans-serif]There is good evidence that there is a silicon fault in the LPC1343 that will allow a timer peripheral to run during deep sleep (and output a match result) if the system oscillator has been changed to the watchdog oscillator and the watchdog oscillator is not shut down in deep sleep. About 5uA is added to the normal deep sleep current of the LPC1343 of 30uA.[/FONT]

[FONT=Helvetica, Arial, sans-serif]No one should rely on this fault remaining in future batches to build software with, such as using the fault to wake up from deep sleep by using a timer output match to trigger start logic.

---

[/FONT]
[FONT=Helvetica][/FONT]
[FONT=Helvetica]Seriously ... it's intentional, NXP did it on purpose, they were the ones who brought it to my attention (thanks to their excellent and very competent technical support staff), and it makes perfect sense.  What's the point of deep-sleep that you can't exit in SW?  If you need to have a physical external change on a pin to wakeup you may as well go directly into power down mode and use the wakeup pin.  Could it be documented better?  Perhaps ... but that's the price of using new technology, and the manuals I believe are still not at a 1.0 release (though I haven't looked in a while).[/FONT]

[lpcware]

Content originally posted in LPCWare by johnhe on Mon Apr 19 09:05:49 MST 2010
[FONT=Helvetica, Arial, sans-serif]My guess is that there is no interest in presenting code that can be easily and independently run to settle issues.

So I did it on my own.

I have done some simple tests with an LPC1343 LPCXpresso board.

These are my conclusions.

There is good evidence that there is a silicon fault in the LPC1343 that will allow a timer peripheral to run during deep sleep (and output a match result) if the system oscillator has been changed to the watchdog oscillator and the watchdog oscillator is not shut down in deep sleep. About 5uA is added to the normal deep sleep current of the LPC1343 of 30uA.

No one should rely on this fault remaining in future batches to build software with, such as using the fault to wake up from deep sleep by using a timer output match to trigger start logic.

I have attached my test software along with a hex file of  the code that demonstrates the fault. Both are in the attached zip file

John Heenan

[/FONT]