Firmware v6.49 vs v5 Power Idle

So I've hooked the bangle.js in series with a multi meter. To my surprise the idle battery usage on the v5 is 3x as small than on the v6.49.

My meter can't read to a precision greater than 1 mA. So its reading 1 mA on v5 and 3 mA on v6.49, since its a factor of 3 increase, it seems it could be problematic for battery life.

Can anyone who has access to power monitor confirm or deconfirm my findings. And does anyone have any pointers/directions/clue to help me find out what could be the root of this?

I think @AkosLukacs had a small project http://forum.espruino.com/conversations/339259/ that streamed energy usage of a device, maybe you can try it for the bangle?

Wow, thanks - so you actually put it in series with the battery? Or you're measuring the current through the USB charge cable?

@Gordon yes i soldered it.
Help me get to the bottom of this @Gordon. Im sifting through recent changes, trying to figure what it could be.

Yes, absolutely - I'll look at this first thing tomorrow. Thanks for taking the effort to really look into this.

To help me out tomorrow - please can you boot it completely fresh (eg BTN1 held down at startup) so it displays the Bangle.js logo and see if it's still drawing too much power? At least then I can know if I even need to bother installing apps.

I did that and it still has the extra power usage utilised. But is there anyway i can confirm i have the .bootrst file for this test to be valid?
I might have deleted it if it showed it visible in the storage list on ide.
@Gordon also, would you like me to test it on v6, instead of v6.49?

v6 is fine. So the problem lays between v6+ and v6.49

I've just spent the last hour measuring power usage trying some different things with a Bangle on 2v06, 2v06.49 and the latest firmwares, as well as different JS, and honestly I can't get it to give me any reading much different (~20%) from 1mA - at least not enough to warrant any noticeable change in battery usage.

I'm reasonably confident in what I'm using to measure power usage as I've used it before on a bunch of stuff too.

So I'm pretty sure that at least with the default apps, and with no apps at all, the power usage hasn't changed. Can you think of anything else that might be causing the change in power usage for you?

If you can load the code i use, on your 6.49??

.boot0
https://pastebin.com/1y9HHHLJ

.bootcde
https://pastebin.com/iN4dp74x

and .bootcde is pulling in:
require("gbridge.wid.js");
require("widbt.wid.js");
from each of these apps.

My code turns BT on (.wake()) if you hold BTN1 for 5 seconds, but you have to do it atleast 3 seconds after the screen comes on.

I cannot test with BangleApp because i put my watch back together. So i've lost my ability to test power usage now :)

Can you give me some insight into where i can find the .bootrst code? within Espruino project.

I notice that the analog pin reading code is changed between the 2 versions. Since i'm calling AnalogRead, could that be a prime suspect?
I mean i tested without using any boot code right. With BTN1, so it can't be that.

I think i should trust my power readings too, since I had it in series with a multimeter. I'm really lost and confused as to what this all could mean...

The user on this forum named @allObjects could be useful in this matter. @allObjects since you have a power measurement capability, could you please test the idle current draw between v6/v5 and v6.49?

I'm right now out in the boonies, but will have equipment at hand for the next two (2) days and try some readings.

Have to get rid of my extra setup do have just the minimum installed as described by @Gordon.

Can you give me some insight into where i can find the .bootrst code? within Espruino project.

https://github.com/espruino/BangleApps/tree/master/apps/boot is the bootloader - however you shouldn't have a .bootrst file unless you actually uploaded it yourself?

Ok, I just tried with your files - still 1mA in idle :(

Don't know if this helps but I've got a big capacitor across the power on the Bangle.js side to help smooth out any peaks of power consumption and make the meter's life a bit easier.

@allObjects it'd be great if you could give it a go too. Honestly, try it with what you have now. Anything that might add extra power draw would be great!

Just an update on this:

I noticed that a Flash memory speed optimisation that went in recently was keeping the CS pin low while in sleep. By putting that high and issuing a power down command to it, I've saved 0.3mA, so idle power consumption is down to 0.85mA now.

However, I then restarted, and with entirely standard firmware that had been showing the lowest power consumption we'd ever had, and with standard apps, it started drawing 3mA

So I'm not really sure how I can reproduce it, but you're totally right. Somehow it can get into a mode where it draws a bunch of power - but that may not have much to do with the JS or even the firmware itself.

@Gordon Thanks for the work and feedback. Not much I can do but sit back at this point, I'm afraid.

I know that the official Bangle Apps boot code is perfectly fine. But i went OCD on efficiency trying to strip down anything I don't need and disallowing apps to run .boot code eg. It didnt' save much, but do you think there is a pattern here. That by reducing the power consumption down to a threshold then it triggers this 3mA? SOunds like thats what you might be implying.

COuld it be a 'time' problem?? I also didnt eval a clock file, i just used the bootcde as my clock code directly.. Hm I mean, like a latency thing of doing stuff slower rather than faster.. after calling .sleep mb ?

To be completely honest, I did notice at one brief moment, the Amperage drop to 1mA on 6.49 at one random point after uploading code to it via RAM function on the IDE. Couldn't make out why my code didn't load, so i assumed it crashed or something. I tried to reproduce it with "reset()" but couldn't.

I think you are most correct when you talk about it like a 'state' ... I think that once it gets into that state , not much corrects it. Except maybe a full restart via power in, which might be why my BTN1 reset restart tests didn't show reduced power consumption?

One of the defining features of my setup is that i use 0.1 brightness(the lowest). This might be an important factor too, somehow.

It's possible flash could have been a problem. Just toggling the CS line adds 0.3mA and if it was left in the middle of a read it could have added 3mA - it doesn't really explain how it stays that way after a reboot though (but maybe some arrangements of files in storage mean that flash reads ate left at addresses that cause increased power usage). I haven't been able to reproduce since fiddling with the CS line code.

It might be worth upgrading to an absolute cutting edge build and trying, just in case I did fix it without realising.

Also I just put the brightness down to 0.1 as well (that was a good thought) but no luck so far.

The other thing is it could be a hardware issue - like maybe something (the accelerometer, magnetometer or IO expander?) gets misconfigured and then never resets properly. It's just frustrating not being able to reproduce it reliably.

Btw, is it better to call this :

targetlibs\nrf5x_12\components\libraries\pwr_mgmt.c

void nrf_pwr_mgmt_run(void)
{
##if NRF_PWR_MGMT_CONFIG_FPU_SUPPORT_ENABLED
    /*
     * Clear FPU exceptions.
     * Without this step, the FPU interrupt is marked as pending,
     * preventing system from sleeping.
     */
    uint32_t fpscr = __get_FPSCR();
    __set_FPSCR(fpscr & ~0x9Fu);
    __DMB();
    NVIC_ClearPendingIRQ(FPU_IRQn);

    // Assert if a critical FPU exception is signaled.
    ASSERT((fpscr & 0x03) == 0);
##endif // NRF_PWR_MGMT_CONFIG_FPU_SUPPORT_ENABLED

    SLEEP_LOCK();

##if NRF_PWR_MGMT_CONFIG_CPU_USAGE_MONITOR_ENABLED
    uint32_t sleep_start;
    uint32_t sleep_end;
    uint32_t sleep_duration;

    sleep_start = app_timer_cnt_get();
##endif // NRF_PWR_MGMT_CONFIG_CPU_USAGE_MONITOR_ENABLED

    DEBUG_PIN_SET();

    // Wait for an event.
##ifdef SOFTDEVICE_PRESENT
    ret_code_t ret_code = sd_app_evt_wait();
    if (ret_code == NRF_ERROR_SOFTDEVICE_NOT_ENABLED)
    {
        __WFE();
        __SEV();
        __WFE();
    }
    else
    {
        APP_ERROR_CHECK(ret_code);
    }
##else
    __WFE();
    __SEV();
    __WFE();
##endif // SOFTDEVICE_PRESENT

    DEBUG_PIN_CLEAR();

##if NRF_PWR_MGMT_CONFIG_CPU_USAGE_MONITOR_ENABLED
    sleep_end = app_timer_cnt_get();
    UNUSED_VARIABLE(app_timer_cnt_diff_compute(sleep_end,
                                               sleep_start,
                                               &sleep_duration));
    m_ticks_sleeping += sleep_duration;
##endif // NRF_PWR_MGMT_CONFIG_CPU_USAGE_MONITOR_ENABLED

    SLEEP_RELEASE();
}

over just :

sd_app_evt_wait();

Seems like there are a lot of reasons why a SoC can't sleep.. :P whilst browsing the Nordic Forums..

Btw, where is most of the power usage values coming from? I see most figures in the low uA range on the forums.. What makes our device use ~0.8mA? I'm surely getting confused by their figures, mb they are referring to only the SoC, whereas we are referring to an entire board?

It seems that just invoking the FPU and not clearing the interrupt, the nRF52 chip couldn't sleep.

This one seems particularly common, have we covered that alreadY? The code above covers it. And we are doing float arithmetic with getBattery .. hmm

Hmm, there's a bunch of extra stuff in nrf_pwr_mgmt_run that we don't really need. Might sound dumb but on some platforms it's amazingly tight getting all the code in, and something like this won't really help matters.

I'll definitely stick the FPU code in there though (although most code uses doubles since it's JS).

However I'm not too sure - there could be some power management issue but there are over 10,000 other Espruino devices out there based on the nRF52832 MCU using the same firmware, and I'd have thought I'd have got a bunch of complaints if it was something really obvious.

The issue is that you can't reproduce it when you want? Once we can reproduce it, then we can simply test some fixes all at once, and find the one that does the magic.

I can only repeat my point from the other the thread: If I reduce interval calls the battery lasts longer. The more interval calls I have the more dramatically the battery duration drops. Just an observation for my case, but I like to remind to this.
In detail: my watch app has an interval event even without active display every second (yes it's not best pratice, but for this although a good idea) Battery lasted with V5 more than one week, even if I paint the watchface without display on. If I do it now with latest fw battery lasts two to three days. From my point of view the interval causes got more battery consumption. I can't tell where the underling problem is (e.g. power saving). But maybe this is a hint.

The issue is that you can't reproduce it when you want?

Basically. I had it happening, but since I improved the flash memory code (which is something that definitely changed in 2v06) I haven't been able to reproduce it. Maybe it's fixed, but I just need more people to try the cutting edge firmware and see if battery life improves.

In terms of floating point, erratas, etc - these are all things that would be an issue on other Espruino nRF52 devices (it could still be a problem, it's just more likely to have been found over the last few years), and there's also no good reason why they would have started to be an issue in 2v06 when 2v05 was ok.

I've added the floating point fix, but at some point just throwing code at the problem when it might be fixed already is going to add more bugs, not fix them.

@Tx can you try installing a 'cutting edge' firmware and see if that fixes the problem?

@Gordon yes, it's now running the latest version. I will report the next days and I will also re-enable the second interval.

@Gordon from the first 30mins - it's looking good. And if I trust the battery level it even charges the watch without a power plug :-)

I've tried the Cutting Edge build version and it seems really good! I hope the battery icon has not been hacked ;) Thanks everyone for the quick fix!