Supported Targets¶

• LPC812
• LPC11u24
• LPC1114
• KLxxZ
• K20D50M
• All mbed STM targets

Please read the target specific comments below. A general small warning: If you have other interrupts enabled, and they request attention after the WakeUp interrupt is set, but before deepsleep is entered, and these take long to handle, it is possible that the WakeUp interrupt is handled before you enter deepsleep. In that case there is no interrupt anymore which should wake it from deepsleep.

Example code¶

// Depending on the LED connections either the LED is off the 2 seconds
// the target spends in deepsleep(), and on for the other second. Or it is inverted 
 
#include "mbed.h"
#include "WakeUp.h"
 
DigitalOut myled(LED1);
 
int main() {
    //The low-power oscillator can be quite inaccurate on some targets
    //this function calibrates it against the main clock
    WakeUp::calibrate();
   
    while(1) {
        //Set LED to zero
        myled = 0;
        
        //Set wakeup time for 2 seconds
        WakeUp::set_ms(2000);
        
        //Enter deepsleep, the program won't go beyond this point until it is woken up
        deepsleep();
  
        //Set LED for 1 second to one
        myled = 1;
        wait(1);
    }
}

Target comments¶

All targets use different implementations, some of these have some things that need to be taken into account. If your target is supported but not listed here, then there is nothing relevant to mention.

Core M3/M4 microcontrollers¶

These microcontrollers cannot wake from deepsleep while they are being debugged. Core M0s can, although their power consumption is very high while being debugged. Generally to exit debug mode you need to power cycle the microcontroller, while making sure the debugger isn't powercycled as well.

On NUCLEO boards you can for example break the connection to the target IC with a jumper, which does this. Most Freescale boards have a USB connector for the target IC (in addition to the SDA USB). If you use this one to power the board, the debugger should not get powered.

LPC11u24¶

This target uses the watchdog timer to generate the necesary interrupts to wake from deepsleep. The reset functionality of the timer is disabled, so you don't need to worry about that. However the library won't work if other code also uses the watchdog timer. Most likely the result is unpredictable.

STM¶

For STM targets the library uses the RTC of these targets. The calibration subroutine is not (yet) implemented, since it assumes that an RTC is quite accurate (which might not be true if it runs as by default on an internal RC oscillator). Currently it keeps the RTC in the default settings of the mbed code. Due to the nature of these settings the maximum time resolution this lib can achieve on those targets is, depending on if a 32kHz crystal is fitted, 3-4ms, instead of the 1ms of other targets.

LPC1114¶

The LPC1114 is special. Not in a good way special. It lacks any kind of regular low-power timer/RTC/WDT which is suitable to wake it from deepsleep mode. What the library does instead is that when the WakeUp command is called, it sets the entire main clock of the device to the watchdog oscillator (at 20kHz). Clock gating is used to disable all peripherals except one timer, this timer then is used to create a pulse on an output pin. Connected to this output pin is an external interrupt, which wakes the device, and restores the original settings.

The first thing this means is that you need an unused pin. Currently by default it is set for dp1 (P0_8). In the relevant code file you can change it to dp2 (P0_9). While this pin generated a pulse, other pwm outputs on the same peripheral which are active will keep running (although very slowly).

The second, and also important part, is that you should NOT set it to immediatly start a timer and enter deepsleep after a reset. Add a wait of a few seconds (random amount) in between (or just other code). When it runs at 20kHz it will refuse to be reprogrammed by the Switch Science LPC1114 mbed board, and I can do the educated guess that ISP programming via the UART also isn't going to work. If you add a wait at the start there is no problem.

Did you ignore my advice and got your LPC1114 bricked? Don't worry (too much), I managed to unbrick all mine again. I used uVision 5, export an LPC1114 project from mbed to have correct device settings. In Project > Options for Target > Debug > Use debugger: CMSIS-DAP > Settings you can change debugger settings. Playing with these can help (I haven't found yet what is required exactly). Now from Flash you can do erase/download. This is giving errors for me. Doesn't matter, what is important is that if you do the right thing (if your code blinks an LED for example that is useful), the code will stop running. Either the uC is set in permanent reset (faint glow of LEDs connected to ground), or it just stops running. At this point you can drag an drop program it again.

Currently due to technical limitations there is no calibration implementation. If there is going to be one it will require dp24 pin.