SAMR21 Sleep Mode

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi ,

 

I'm working on SAMR21 , I want the transceiver + micro go to sleep mode.

Here are the steps I follow.

Transciever goes to sleep mode first and then the Micro controller goes to OFF mode.

I cannot see the results I expect to see. I still see a current consumption of 2.2 mA doing so,??

TRX goes to sleep mode and MCU goes to OFF mode (least power consuming state)

 

Thanks,

Vivek

Vivek Anchalia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am having the same issue (see [1] and [2]) with SAM R21 on an XplainedPro board. I always get currents larger than 400 µA and have no idea why...

 

 

[1] https://community.atmel.com/forum/wakeup-standby-sam-r21

[2] http://www.at91.com/discussions/viewtopic.php/t,25493.html

 

 

Dominik

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have made measurements for certain power modes available in sam r 21. 

 

 

AT86RF233  Radio 
SLEEP Sleep
TRX_OFF  Idle
BUSY_TX Tx
RX_ON   Listen
BUSY_RX Rx

 

SAMR21  Core 
ACTIVE (while(1) ) Active
STANDBY Sleep
 
 

 

 

 

Core Radio Datasheet Current Measured Current (mA)
Active Sleep 4,923 5,289
Active Idle 5,123 5,629
Active Rx 16,22 11,93*
Active Tx 16,72 6,7*
Active Listen 16,72 11,09*
Sleep Sleep 0,00583 0,23
Sleep Idle 0,00783 0,581
Sleep Rx 12,88 7,08*
Sleep Tx 13,88 5,83*
Sleep Listen 13,38 5,94
     

 

Since no data frame was communicated, TX; RX current consumption was much less. 

Is there anybody who worked with SAM R21 to measure each state current consumption. I just need to confirm that my readings are error free

 

 

Regards
Tomy

Last Edited: Tue. Feb 20, 2018 - 09:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The SAMR21 is just a SAMD21 and an AT86RF233 together in a single package.

 

From experience, I would suggest that you debug this with a separate SAMD21 chip and an AT86RF233 chip - so that you can actually see where the current is going ...

 

It should certainly be possibly to get well below 2.2mA !!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Find a way to measure without a jtag programmer. In my experience, that raises the current and avoid the microcontroller to go to sleep. I'm running a L21 in standby mode with 20uA measured.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's a good point.

 

You need to be sure where, exactly, the 2.2mA is going - if it's not going into the R21 chip, then no amount of fiddling with the R21 is going to help.

 

You also need to check if it's "leaking" through IO pins to other connected stuff ... 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Old topic but did anyone in the meantime manage to get a samr21 under eg 100ua in core sleep/ radio sleep mode ?

 

I've been trying to get there for the past few days but i cant get lower than 460/520 uA.

 

The 460 is if i go into core sleep mode before calling MiApp_ProtocolInit (and therefore i do not call  MiApp_TransceiverPowerState(POWER_STATE_SLEEP) because spi etc toward the radio have not yet been initialized then so the radio was never active and the call would hang due to uninitialized spi).

 

The 520 is if i go into core sleep + radio sleep at any point after doing MiApp_ProtocolInit . 

So it seems at least 60 uA is 'lost' once you talk to the radio which you cannot recuperate by doing a MiApp_TransceiverPowerState(POWER_STATE_SLEEP) . Suggestions/experiences are welcome ( I also call trx_spi_disable(); when i put the radio into sleep so i hope this means the spi bus is not leaking or something like that).

 

The other 460 I have no idea, I have no debugger attached (otherwise i go to 7ma in sleep) and i have checked all the pins to see if there is leakage there .

I have made the most simple application possible by just doing

 

int main ( void )
{   
    irq_initialize_vectors();
    system_init();
    delay_init();

    cpu_irq_enable();

 

    //output clock  0 and 1 to make sure core goes to sleep

    struct system_pinmux_config pin_mux;
    system_pinmux_get_config_defaults(&pin_mux);
    pin_mux.mux_position = MUX_PA14H_GCLK_IO0;
    system_pinmux_pin_set_config(PIN_PA14H_GCLK_IO0, &pin_mux);
    
    pin_mux.mux_position = MUX_PA15H_GCLK_IO1;
    system_pinmux_pin_set_config(PIN_PA15H_GCLK_IO1, &pin_mux);

        // Debug : go directly into standby    

        {

            GPIO_init(); -> this sets all the pins in an okay state for low power
            system_set_sleepmode(SYSTEM_SLEEPMODE_STANDBY);
            system_sleep();
        }
-> 460 uA at this point (the funny thing is the first time i tried this i think i saw around 64 uA but now i cannot reproduce it anymore so maybe i was just dreaming/misreading (?) )

 

I have only clocks 0 and 1 in the system (i have not activated the WD or the RTC) and i can see them deactivate on the output clock io pins when i go to sleep:

  * 48 MHz DFLL feeds system clock via GCLK0
  * 32 kHz external oscillator feeds the DFLL via GCLK1

 

So what is still eating 460 uA :/ ?

 

 

Note: I do know i have 20uA loss wrt to datasheets because apparently Farnell supplied earlier than rev D chips (in 2019) so

#if (SAMD21 || SAMR21)

       if (rev < _SYSTEM_MCU_REVISION_D) {

             /* Errata 13140: Make sure that the Flash does not power all the way down

             * when in sleep mode. */

             NVMCTRL->CTRLB.bit.SLEEPPRM = NVMCTRL_CTRLB_SLEEPPRM_DISABLED_Val;

       }

#endif

is triggered.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For ultra low power applications you have to check every leakage that may flow:

->disable the pmux before going to sleep

->disable every peripheral before going to sleep (a timer already consumes ~30-100uA)

->check peripherals which may draw current, e.g. a connected uart device may draw ~100-200uA from RXD pins even if the uart device is off

->atmel ice connection draws ~50-100uA

 

 

check whether the mcu really sleeps, see http://infocenter.arm.com/help/i...

Entering STANDBY mode: This mode is entered by executing the WFI instruction with the
SCR.SLEEPDEEP bit of the CPU is written to 1.

 

One thing to the hardware:

How are you measuring the current?

e.g. if you look into the schematic there is a resistor devider on J300 from VBUS = 5V (USB) to GND (R328 & R330 @ 47k each  -> I = U/R = 5000mV/94000Ohm = ~50uA)

maybe you have some pull-up/down resistors in your measurement circuit?

 

Hope this helps

 

Flo1991

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

Thanks for the response.

 

> ->disable the pmux before going to sleep

What do you mean by 'the pmux' ? There is a bit for each pin to select if you want it connected to one of the peripherals or not and that is called pmuxen, but i am not aware of a pmux block or something that you can enable/disable.

 

> ->disable every peripheral before going to sleep (a timer already consumes ~30-100uA)

I have made an even simpler test:

int main ( void )
{   
    system_set_sleepmode(SYSTEM_SLEEPMODE_STANDBY);
    system_sleep();
}

 

with:

system_set_sleepmode:
      <...>
        case SYSTEM_SLEEPMODE_STANDBY:
            SCB->SCR |=  SCB_SCR_SLEEPDEEP_Msk;
            break;
            
            
system_sleep:
    __DSB();
    __WFI();

 

So nothing is enabled, and all the pins should be in reset state (inputs with no pull)

And since i only have 2 generic clocks in the system (0 and 1) and I output both of them on the IO pins to make sure they are nut running, i think there is no way that a peripheral such as a timer could still be running and consuming current (?).

But I still have the 450uA consumption.

       

> ->check peripherals which may draw current, e.g. a connected uart device may draw ~100-200uA from RXD pins even if the uart device is off

> ->atmel ice connection draws ~50-100uA

 

Except for power supply, nothing is connected to my board anymore.

I have measured all pins to the peripherals on the board and nothing is in a power consuming state so I am guessing it has to be something in the mcu (also because the rest of the board is mostly identical to a previous board with another mcu where i did manage to get to 50 uA).

Sadly i cannot isolate the power going to the mcu so I am not 100% sure, one of the next steps at this point is to strip of all components of a board leaving only the mcu to be 100% sure i did not overlook something.

But before doing that I would like to know if it is even possible to reach the advertised power consumption with the above mini program, hence the question. 

 

> check whether the mcu really sleeps

The bits you mention are set by the calls made, cfr above.  (And I also outputted the clocks 0 and 1 which go off during sleep).

 

 

>How are you measuring the current?

>e.g. if you look into the schematic there is a resistor devider on J300 from VBUS = 5V (USB) to GND (R328 & R330 @ 47k each  -> I = U/R = 5000mV/94000Ohm = ~50uA) maybe you have some pull-up/down resistors in your measurement circuit?

 

I have a proprietary board with the chip so I hope we are not talking about the same schematic :) (also because there is no usb on it :P ) . I measure the current with a tektronix tx3 in series with a labo supply.

 

 

 

                 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought you also use the xplained pro... so is it possible that you provide some more information about the schematic?

In general electrolytic capacitors also have a leakage current in the uA range...

Refering to the PMUX I mean the pin multiplexer, it should be disabled for all pins in sleep mode (pmuxen for each single pin --> disabled).

I have no SAMR21 to test, but refering to the datasheet the included RF part seems not to be disabled by the mcu sleep command:

35.6.2 DEEP_SLEEP state
The DEEP_SLEEP state is used when radio transceiver functionality is not required, and thus the Atmel AT86RF233 can
be powered down to reduce the overall power consumption.
When the radio transceiver is in PREP_DEEP_SLEEP state the microcontroller forces the AT86RF233 to DEEP_SLEEP
by setting SLP_TR = H. If CLKM provides a clock to the microcontroller this clock is switched off after 35 CLKM cycles.
This enables a microcontroller in a synchronous system to complete its power-down routine and prevent deadlock
situations. The AT86RF233 awakes when the microcontroller releases SLP_TR and goes into TRX_OFF state. This
concept provides the lowest possible power consumption.

 

Under 42.15.5 Current Consumption Specifications:

IPLL_ON Supply current PLL_ON state with active RPC mode 450 μA

ITRX_OFF Supply current TRX_OFF state 300 μA

[...]

IDEEP_SLEEP Supply current DEEP_SLEEP state 0.02 μA

 

see Figure 36-1. Basic Operating Mode State Diagram for entering deep sleep of the rf part

 

 

Flo1991

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah after another day of searching I stumbled upon the issue  : in my tests where i thought i did put the RF part in sleep  (when i got 520 uA) it turns out it was just in off mode.

This was because the function in the ASF framework for putting the RF part in sleep (of which the documentation states it puts the RF part in deepsleep) is not doing that at all (but it puts it in off)

The command to put it in deepsleep (0x10) is not even present in the h files.

Makes you wonder what atmel/microchip was thinking there, i would like to send them an invoice for lost time.

 

Anyway thanks for your support!