Pico power consumption down to 0.02mA

Thank you Gordon... but, sorry, I have another problem now : when I download (with Chrome) the firmware with your link above, it is impossible to reconnect the pico (LED red ON)... The only way to restart it is to download the old 1.85... Have you an idea ?

It looks like something has gone wrong with the build I'm afraid (looks like there isn't actually a binary in that directory at all at the moment) - I'll take a look in the next hour or so.

I fixed travis in my fork, btw. https://github.com/tve/Espruino Latest build https://travis-ci.org/tve/Espruino is not all green...

Thanks - looks like I git added the fix for the original boards yesterday but forgot to commit! Thanks for the heads up about travis - is it safe to pull in the ESP8266 SDK version changes from your branch as well?

If you try now, and make sure you use espruino_*_pico_1r3_wiznet.bin then it should work better.

Thank you Gordon, now I have a consumption of about 20uA even if I disconnect the USB. But... if I disconnect the battery and I reconnect it the consumption increases to about 550uA. It's better but not enough for my purpose. Could you do something ?

Are you sure this isn't the original problem of non-grounded pins picking up interference? It could also be related to pins B6 and B7 (if you have pulled either of those down), as by default they are configured as the UART.

This is one of the things I tested when I did the release, so I'm pretty sure you can just plug it in and get low power consumption if you've enabled deep sleep in your saved code.

Hi Gordon,
Sorry, I have checked my setup and all is OK with GND. I observe the following points :
1) I save the code, set deep sleep, disconnect USB and the consumption is about 30uA : OK
2) I disconnect the battery and reconnect it : the consumption increases to 600uA
3) I reconnect USB and connect the board (with IDE) and set deep sleep : always 600uA
4) The only way to obtain 30uA is to restart with point 1

I have done these 4 points with and without B6 and B7 to GND. The best result is without.
I also tested with B6 and B7 „digitalRead“ or not… the problem is the same.

The firmware is 1v85.227 (I hope the link above is OK) and the code is :

digitalRead([B0,B15,B14,B13,B10,B1,A7,A6,A5,A4,A3,A2,A1,A0,A10,B9,B8,A8,B7,B6,B5,B4,B3]);
setInterval(function() {
  digitalWrite(LED1, 1);
  setTimeout(function () {
    digitalWrite(LED1, 0);
  }, 20);
}, 10000);
setDeepSleep(1);

Thank you for your help !

When you say 'I save the code, set deep sleep, disconnect USB' do you mean you manually call setDeepSleep(1) after saving? Just uploading the code as you posted it should really be enough to have Deep Sleep enabled.

edit: but yes, I just tried it here and I get the same thing as you (albeit somewhere around 300uA)

I've asked ST if they can take a look at this - it seems like there's something strange with the USB driver/hardware, because as far as I can tell nothing is done differently in software either way.

OK... rather good news if you get the same thing as me :)
Thank you to see with ST... because, for an embedded system, it's a little bit annoying to have to connect the USB and reprogram before using the battery !!!

300uA is in the values I mesured... there are many variations for this "strange mode"

So... wait and see :)

Thanks and best regards

Hi Gordon,

Have you some news from ST about this problem of consumption ?

Best regards

Hi - I haven't got any solution yet I'm afraid - I did hear back, but just with a suggestion for debugging it, which I haven't had time to do yet.

Sorry for the delay - I'll have another go at it next week. I'd really hoped there'd just be an obvious answer since it seems like something that pretty much everyone using USB on a battery powered device would want to do - but it seems not!

Have you tried this recently? Versions 1v86 and 1v87 of the Espruino firmware seem to work fine. On the meter here, once powered on with the code above it reads 16uA (and just to check I can flash it with 1v85 and get the described problems).

Hi,
let me renew the "Pico power consumption" issue.

I have Espruino Pico v1.4 (fw 2v01) and tried to reach as less consumption as possible using LiPol 3.7V 1100mAh.

My code and test results:

// test 1.1: **~460uA**
digitalRead([B15,B14,B13,B10,B1,A7,A6,A5,A4,A3,A2,A1,A0,A10,B9,B8,A8,B7,B6,B5,B4,B3]);
setInterval('digitalPulse(LED1,1,10)',5000); 
setDeepSleep(1);

// test 2.1: **~500uA**
digitalRead([B15,B14,B13,B10,B1,A7,A6,A5,A4,A3,A2,A1,A0,A10,B9,B8,A8,B7,B6,B5,B4,B3]);
setSleepIndicator(LED1); 
setInterval(function() {}, 5000);
setDeepSleep(1);

// test 3.1: **~400uA**
digitalRead([B15,B14,B13,B10,B1,A7,A6,A5,A4,A3,A2,A1,A0,A10,B9,B8,A8,B7,B6,B5,B4,B3]);
setInterval(function() {
  digitalWrite(LED1, 1);
  setTimeout(function () {
    digitalWrite(LED1, 0);
  }, 20);
}, 5000);
setDeepSleep(1);

Unfortunately, no pins are grounded.

Could you tell me, how is grounding important for this issue? What can be suggested else to reduce consumption?

In fact, "pin grounding" is not good for me. Because entire B3-B7, A8 are linked with InAir9b module.

Hi,
Just to mention that the schematics show 100 ohms resistor in series with each led.
So, in your test 3, 20 ms on every 5000 ms should give us: 20 ms / 5000 ms*(3.3v-voltage drop of led) / 100 ohm.
If we assume a voltage drop of 0,7v we get 0.104 mA for lighting the sole led1 20'ms every 5000 ms.
That said, the way you connect your battery could keep usb drivers awaken and trying to detect some data connection. This is just an hypothesis 🤔

I am very interested with this kind of problem too... Keep us informed of your results 😓

Thanks a lot!
a) all measurements of the current as above were made between flashes of LED;
b) I got your idea and will extend deepsleep time, in order to give time USB driver go rest.

So, my next report (try 2) for all three tests as above for three-four minutes each; using multimeter UT50B made by UNI-T:

// test 1.2: ~61uA
digitalRead([B15,B14,B13,B10,B1,A7,A6,A5,A4,A3,A2,A1,A0,A10,B9,B8,A8,B7,B6,B5,B4,B3]);
setInterval('digitalPulse(LED1,1,10)',60000); // actual repeat time is about 50 seconds
setDeepSleep(1);

// test 2.2: ~48uA
digitalRead([B15,B14,B13,B10,B1,A7,A6,A5,A4,A3,A2,A1,A0,A10,B9,B8,A8,B7,B6,B5,B4,B3]);
setSleepIndicator(LED1);
setInterval(function(){
}, 60000); // actual repeat time is about 50 seconds
setDeepSleep(1);

// test 3.2: ~59uA
digitalRead([B15,B14,B13,B10,B1,A7,A6,A5,A4,A3,A2,A1,A0,A10,B9,B8,A8,B7,B6,B5,B4,B3]);
setInterval(function() {
  digitalWrite(LED1, 1);
  setTimeout(function () {
    digitalWrite(LED1, 0);
  }, 20);
}, 60000); // actual repeat time is about 50 seconds
setDeepSleep(1);

Wow, power consumption has drop almost 10 times! Anyway, I did not reach result mentioned above my notes.

Any comments/suggestions are welcome!

NB: here is open question, that is about power consumption in case of all connected circuits to PICO, like InAir9B, PIR sensor and 4 pcs DS18B20...

So what changed? Just the multimeter you used?

About the grounding - it's not required, but what can happen is electrical interference gets on pins which makes them (internally) toggle between 0 and 1 quickly. That toggling actually uses up power. One way to stop that is to ground pins - or you can just set them to outputs - it's maybe not as good but it's far easier!

It's a massive problem on the nRF52s, less so on the STM32 but you could try:

digitalWrite([B15,B14,B13,B10,B1,A7,A6,A5,A4,A3,A2,A1,A0,A10,B9,B8,A8,B7,B6,B5,B4,B3]);

instead of digitalRead and see if that helps lower it?

Hi Gordon,
thanks for your comments!

..the multimeter was not changed, just mentioned it. In tests nr.2.x and later the InAir9b module was disconnected from all pins of PICO.

It helps!!!

// test 3.3b: 24uA
digitalWrite([B15,B14,B13,B10,B1,A7,A6,A5,A4,A3,A2,A1,A0,A10,B9,B8,A8,B7,B6,B5,B4,B3],1);

instead of

// test 3.3: 68uA
digitalRead([B15,B14,B13,B10,B1,A7,A6,A5,A4,A3,A2,A1,A0,A10,B9,B8,A8,B7,B6,B5,B4,B3]);

Unfortunately:
1) my tests results (e.g. 1.1 and 1.2) have a little differ. Probably, on the reason of battery voltage is down from test to test;
2) there is pure test, i.e. without radio module, sensors and another loads on PICO pins. How to reach the same result in case of many PICO pins are connected?

The difference may well be down to what I'd said above - just interference. I know I've noticed that just having me touching an IO pin that is an input is enough to drastically increase power usage - so perhaps even having your phone closer to the board can do it.

Thanks a lot, Gordon!
I will try to assemble complete functional board and test it focusing on the power consumption, and share result/problems here...