Just tried with the diff below and couldn't see any difference on our energy consumption test equipment.
We tried to measure the energy consumption over the external power pins which might be imprecise. The xpro has support for energy measurements on the jumper'd pins next to the buttons.. we didn't try that.
Maybe someone else can try this PR with their measurement tools?

diff --git a/core/kernel_init.c b/core/kernel_init.c
index a57f119..c18b6e6 100644
--- a/core/kernel_init.c
+++ b/core/kernel_init.c
@@ -64,8 +64,8 @@ static void *idle_thread(void *arg)
             lpm_set(LPM_IDLE);
         }
         else {
-            lpm_set(LPM_IDLE);
-            /* lpm_set(LPM_SLEEP); */
+            //lpm_set(LPM_IDLE);
+            lpm_set(LPM_SLEEP);
             /* lpm_set(LPM_POWERDOWN); */
         }

I'll have access to my lab again next week. I'll give it a go then. Thanks

@saurabh984 I addressed your comments.

@LudwigOrtmann I tried to test this PR with:

static void button_handler(void *args)
{
    puts("Button Handler");
    lpm_arch_awake();
}

int main(void)
{
    puts("Test LPM modes\n");
    /* this is the user button on samr21-xpro */
    gpio_init_int(GPIO_1, GPIO_NOPULL, GPIO_BOTH, &button_handler, 0);

    puts("Init lpm");
    lpm_arch_init();

    puts("LPM_ON");
    lpm_arch_set(LPM_ON);

    puts("LPM_IDLE");
    lpm_arch_set(LPM_IDLE);

    puts("LPM_SLEEP");
    lpm_arch_set(LPM_SLEEP);

    puts("LPM_POWERDOWN");
    lpm_arch_set(LPM_POWERDOWN);

    puts("LPM_OFF");
    lpm_arch_set(LPM_OFF);
}

I couldn't awake the board after LPM_SLEEP. Can you tell how this is done?

@PeterKietzmann Try commenting out the cpu_init() (shown below) code from lpm_arch_awake(void) please?

if (current_mode == LPM_SLEEP) {
        /* Re-init */
        cpu_init();
    }

@saurabh984, I commented this line out. With this change I could also awake from LPM_SLEEP and enter LPM_POWERDOWN. But I did not came out of LPM_POWERDOWN (btw: I haven't looked into the boards documentation). Then I measured the current through the "current measurement header". My results:
LPM_ON/LPM_IDLE : 560 uA
LPM_SLEEP : 535 uA
LPM_POWERDOWN : 500 uA
I don't know if this are the expected values: In addition: First I tried to measure the current through a 10Ohm shunt-resistor and an Oscilloskop which "crashed" the board in any way. Then I took my multimeter (ammeter) and had the same problems. Once I switched the multimeter-range to MICROampere the internal resistance seemd to be small enough to fit the measurement.

@saurabh984 did you experience the same?

@PeterKietzmann, from p1048 to 1051/1138 (samr21 datasheet), you can find the power consumption of the samr21. There is also a schematic about how to use the measurement pin.
Will try it in the comings days hopefully

Here are my results with @PeterKietzmann source code (above):

(h:14 m:4 s:56) Init lpm
(h:14 m:4 s:56) LPM_ON
(h:14 m:4 s:56) LPM_IDLE

LPM_IDLE/LPM_ON: 1,62mA

(h:14 m:5 s:1) Button Handler
(h:14 m:5 s:1) LPM_SLEEP

LPM_SLEEP1,38mA

(h:14 m:5 s:5) Button Handler
(h:14 m:5 s:5) LPM_POWERDOWN

LPM_POWERDOWN : 1,08mA

(h:14 m:5 s:21) Button Handler

Here I've got 0,39mA but I can't wake up, Interruption doesn't work anymore.

If I keep cpu_init(), I'm not able to wake up from LPM_SLEEP as well.

By the way, @PeterKietzmann, you should use a GPIO_PULLUP and GPIO_RISING otherwise the interrupt doesn't work properly.
gpio_init_int(GPIO_1, GPIO_PULLUP, GPIO_RISING, &button_handler, 0);

FYI concerning SCB->SCR:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/CIHFDJCA.html

@bapclenet what do you mean by the SCB is not mentioned for power management?
The SLEEPDEEP bit in the SCB SCR decides if the CPU should go to STOP mode or WAIT mode when wfi is executed.

edit: I am speaking from experience with CM3/4 CPUs, I did not look up CM0 docs on this.

Sorry, my bad, I didn't know that before, I've just seen it.

@bapclenet your results seem somehow reasonable even if they appear to be kind of small, comparing to the datasheet (worse are mine :-) ). But honestly I didn't compare the clock setup etc. . Now the question is: is there anybody out who has a deeper knowledge with this MCU and with (low) power modes? Otherwise I need to spend some time in going into detail.

@bapclenet can you explain in detail how you build your setup? Looking at the datasheet on page 1054 it feels like I can't directly access the needed pins or have to use an external power supply not from USB.
In the user guide on page 7 sec. 3.3.1 you can read that it's possible to measure the consumption through the pins on which the jumper is on. They have a different naming scheme to the pins mentioned in the datasheet. What are your doubts using these?

Sorry for all these questions. I don't want to spend too much time in this and you already did these steps.

@PeterKietzmann, I use a Multimeter from Agilent.

• in VCC target
  Ground in VCC MCU

There are the same pins as in the datasheet. What I'm doing is removing the header (Datasheet p4 - CURRENT MEASUREMENT HEADER) and plug them to my multimeter.

I think (not sure about that), whatever the source is, there is a regulator which transforms 5V to 3.3V, and after the transformation, there are those two pins where you can measure the current before going to the MCU.

Does it make sens?

For more details:

Yes and no. Measuring the current through the "current measurement header"-pins is reasonable and the way I already did (some time ago). What I don't understand is the hint you gave me with the schematic in the datasheet (p. 1054). Anyway, if I see it right and understand correctly you just power your board by the pins and not by an USB connector and you measure the current through the measurement extension header.

I think this PR will need a lot of attention so I don't think it will make it for the release. What's the status BTW?

@MichelRottleuthner did you already give it a try?

@PeterKietzmann Nope. It's on my todo list but I think it will take a few weeks before I have time for that.

Maybe @aabadie wants to take a look ;)

Hey all. Can I help get this merged in for the upcoming release? I have used it, along with a few other changes, and have a SAMR21 running at 5.2uA idle and 15uA average sampling temperature at 1Hz

@immesys, you're welcome to help us merging this PR :-)
How did you measure the current (can you provide a schema) ?
Did you try all different modes?
I remember that we had some problem to wake up from LPM_OFF, have you tried?
If you don't have a lot of changes, you can create a PR on LudwigKnuepfer:samd21_lpm branch (with rebase) or if it is totally different, create a new one.

So, the good news is yes, it is waking up fine from lpm off, the bad news is that the code is a little messy (as things get when you are just trying to make it work). I am busy splitting things up into independent PRs, so things like adding radio sleep to netdev, switching the xtimer source to ULP OSC32.

I could really use a shepherd, as some of these changes are in core code and change default behavior (I use FLL instead of PLL saving a bit of energy, and I source it from the ULP instead of the 8mhz RC, which costs accuracy but saves energy). I am busy running experiments to quantify the benefit of each change individually so that the riot core devs can decide if each one is worth it.

@kaspar030, @gebart, would you be willing to act as a shepherd? I would also volunteer but have only time in about two weeks from now.

@immesys it's great to see your efforts improving the sam* support in RIOT! Would it help you to merge this PR "as is" (or with slight adoptions which you would need to propose ;-) )?

I use this file as-is, so it would definitely help to merge it. The slight changes elsewhere are too invasive to just merge, I will need to discuss them with the core maintainers to work out the best way to do them.

@LudwigKnuepfer would you rebase this PR once more? If not @immesys can you take it over (closing this one and opening an updated PR)

I would not mind rebasing, but it didn't actually have any changes, I merge it as-is with no conflicts. In fact at the moment the idle thread (in kernel_init.c) doesn't actually put anything to sleep so merging this file shouldn't even change the behavior of existing code (which is either a feature or a problem depending on how you look at things)

@immesys I do agree with you but regardless of that I'd like to see Murdock pass, so the PR should be updated. (It's still based on Travis, so kind of old :-) )

I will rebase.

Should I also squash and mark as ready for CI?

Yes please! But probably I'm just back on Monday.

@LudwigKnuepfer, squash?

@OlegHahm I did.

Congrats for this PR!