ASF Power Management for Samb11 Xplained Pro

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

Hi,

 

Have an application that's coming along nicely for Samb11 on Xplained Pro and custom PCB; however, getting the device into ULP mode and power usage down to what the Samb11 SoC suggests is its ULP sleep mode is another story...

 

When I used the Data Visualizer and observe active BLE (beacon for testing), I see 3.6 ma of current consumption, then it drops into what I would expect to be ULP sleep mode, where it should be drawing less than 5 to 10 microamps.  What I actually see is very different - constant stream of pulsing that averages around 63 microamps. It's as if it never really fully goes into ULP sleep mode and some kind of background task is running.

 

There are no examples that actually demonstrate putting the Samb11 into ULP mode, yet this is the device's primary value proposition - Ultra Low Power!  The Samb11 does not appear to support the Power Manager driver/subsystem, which other Sam devices do.  The ASF BLE subsystem documentation is currently throwing a 404 Page Not Found error.  Needless to say, this makes solving these kinds of problems more challenging than they should be (and wastes a lot of time).

 

I'm attaching my project source code, which is a public project anyway, along with the Data Visualizer screenshots. 

 

The attached Data Visualizer show the average Power being consumed by the Samb11 during operation. Measuring current consumption as described in Section 4.3.4 of the Atmel Xplained Pro User Guide:

 

1) On Xplained Pro board, set the two current measurement headers as shown in the attached drawing "DataVisualizer-PowerHeaders".

2) Next, open up the Data Visualizer tool from Tools menu, then choose Connect. Then choose Power, and click on gear icon to configure for averaging at 16 samples.

 

As shown in the attached images, the average power being consumed by the board is far higher than what's expected in ULP sleep mode. The average with no interrupt/processing activity is around 66.7 microamps (instead of 1.1 to 2 microamps in ULP mode). In the attached DataVisualizer-Power image, you can see the spikes up to around 3.6 ma when the BLE radio is activated after coming out of sleep mode.

 

The following are attached:

 

- startup_template_app.c - source code to the prototype BLE app for Samb11

- DataVisualizer-PowerStandby.jpg - screenshot of "standby" operation that should be 1.2 microamps with no activity, but which shows average power consumption due to high frequency power spikes averaging 66.7 microamps

- DataVisualizer-Power.jpg - screenshot of a wakeup cycle, whereby BLE and MCU fully awaken and perform a processing cycle, then go back to sleep, using up to 3.6 ma (normal, expected behavior)

- DataVisualizer-PowerPulse.jpg - screenshot of PowerStandby chart with the X-axis increased to show the power pulses that are consuming unexpected power when MCU is supposed to be asleep (it's obviously not)

- DataVisualizer-ULP_DesiredState.jpg - screenshot of the Samb11 specs, where it states what proper ULP mode should be with flash/RAM retention, RTC, etc. running.

 

So, we need to understand why "sleep" power consumption is so high. It would appear that we are not actually getting into ULP sleep mode, but instead are in some kind of BLE "polling" mode after calling at_ble_event_get() to yield the main loop for BLE processing.

 

Any guidance or suggestions would be greatly appreciated.

 

Rick

 

Attachment(s): 

Last Edited: Sun. Sep 17, 2017 - 04:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good news and bad news.  First the good.  On my custom PCB, my Fluke bench meter shows just 2 microamps (.002 on mA scale) during the ULP sleep period.  This means Samb11 is, in fact, sleeping in ultra low power mode.

 

Now for the bad. This means the same program running on the Xplained Pro board with its built in current measurement instrumentation is dead wrong. I don't know what it's reading, but it's not current being drawn from the Samb11 MCU.

 

So this item is now resolved.  The issue is actually with the Samb11 Xplained Pro and/or its Data Visualizer current measurement.