Thanks guys. I’m running 0.6.0, which may be the reason I’m seeing the 50mA during sleep. Still not sure which sleep mode is causing this default 50mA charge rate though? Is it any form of sleep, just deep sleep, sleep network standby, etc?
BTW, I’m not setting charge current like @RWB is, but I don’t see why that should be an issue since I’m good with the default 500mA…for now. 
Just add those 2 PMIC lines of code to your setup and the problem should be solved no matter which Sleep mode your using.
I have tested this with 0.6.0, and have found some pretty interesting results on the allowed charge current in SLEEP_MODE_DEEP. Here are some measurements I took with the following scenarios.
For all graphs, Right axis and white are voltage. Left axis and red are current. 20 seconds between changing the input voltage.
Normal mode (main loop running) and PMIC functions OFF, charge current varies, but is pretty good as high as 500mA.
Normal mode (main loop running) and PMIC functions ON, charge current varies, but is pretty good as high as 500mA.
In SLEEP_MODE_DEEP mode and PMIC functions OFF, charge current stays low, around 100mA.
In SLEEP_MODE_DEEP mode and PMIC functions ON, charge current stays low, around 100mA.
In Conclusion - PMIC functions being on does’t help charge current whether it’s in SLEEP_MODE_DEEP or not. What seems to affect charge current the most is the sleep mode.
I can’t figure out how to update to 0.6.1-rc.1 yet, so when I do I’ll post another graph to see if it’s fixed. 
I’ve updated to 0.6.1-rc.1 and re-tested (this time with an adjustable 3A regulated power supply BK Precision). I tested all sleep modes. I also tested with a second Electron to verify hardware is good. It’s important to note that the measured SOC of the battery during these tests was between 40-60%. I also tested using SEMI_AUTOMATIC mode and System thread enabled.
For all graphs: White line (input voltage) is increased manually with Coarse adjustment. Red line (input current through Vin).
No sleep mode. PMIC functions ON.
No sleep mode. PMIC functions OFF. White line (input voltage) is increased. Red line (input current) peaks at 550-600mA.
SLEEP_MODE_DEEP mode ON, PMIC functions ON.
SLEEP_MODE_DEEP mode ON, PMIC functions ON, Electron #2!
SLEEP_NETWORK_STANDBY mode ON, PMIC functions ON.
System.sleep(long seconds) mode ON, PMIC functions ON.
I think this might be a smoking gun. In this graph, I let the main loop run but didn’t turn on the Cell modem. So does the Cell modem have to be on for the charge current to increase?
In conclusion: In ANY sleep mode (SLEEP_MODE_DEEP, SLEEP_NETWORK_STANDBY, and normal sleep) and also with Cell modem off, charge current is limited to 100mA. Adding PMIC functions do not increase charge current past the default value. The only way to get up to the highest charge current of 550mA is while the main code is running and no sleep mode is assessed.
Sorry if I missed that point, but just to clarify: You are measuring the “charge current” on the LiPo and not on the supply side of the device?
This is on the Vin supply side (because I didn’t want to destroy a battery terminal). My fault for not being specific. I probably should have measured current running through the LiPo.
Given the 90% efficiency of the BQ24195, I guess we have to deduce what that might be from my graphs. I could also go back and remeasure the current across the battery terminal the two modes.
This is what I use for battery testing. There’s a switch and also male and female header pins on the + lead. With the header pins connected, the battery behaves normally, but I can separate them and stick a meter inline for current measurements.
If you apply power to the Vin terminals while the Electron is in sleep modes you will get the 100ma charge limit.
If you use my PMIC code to bump charging current to 1amp then once the setup loop runs the charging can go up to 1 amp.
Now this higher charging current will hold as long as the power applied to Vin remains regardless of charging current, so you will still be able to charge at the higher currents even in deep sleep. This should be no problem during the daylight hours with a solar panel attached to Vin.
If you remove power to the Vin terminals during deep sleep then it will revert back to 100ma charging until the setup code runs again.
Love your electrical tape setup. 
I’ll use the spare battery from the next Electron I kill. I’ve already killed one of them.
In that case you are also measuring the demand of the device itself and not only the charging current - and go with @RWB's suggestions 
I wonder if this is related to the problem we are seeing?
I had the same: only a solarpanel, no battery connected and it started up, browned out and was bricked.
Did any leds come on when plugged into usb? I am noticing that half of the time its not a bricked device and just a battery with a voltage below 3.5V. Sometimes the PMIC doesn’t charge it at all. I am writing code to read the pmic info every minute and see why.
Nvm, noticed you said you didn’t have a battery attached. 
3 posts were split to a new topic: Electron Red Charging Status LED Flashing at 1Hz rate, not charging
I had an Electron bricked after the battery dropped. My setup was 4xAA Energizer L91 connected to VIN, VBAT resistor removed and an external 3.3V source applied to the VBAT pin. After the batteries drained over the course of 3 days I observed 4.35V on VIN and 1.65V on 3V3 and the RGB LED wasn’t lit (still 3.3V on VBAT), saw a slow blink on the charge LED. I left the Electron alone for 24 hours, then disconnected power from VIN and hooked up USB and got a dim blue LED and no RGB LED. I hooked up a ST-Link and saw the full flash was erased.
Why are we still not setting the brownout in system firmware? It might not completely solve this issue, but it’s good practice and I don’t see how it can hurt. @jvanier proposed this a long time ago, but the issue was closed. I’m adding his code to my application and will be running some more battery drain tests in the future and will see if this happens again.
This is still open? Interesting. I observed a problem with a prototype using an Electron recently which may be this bug, or something similar. I did not take exact measurements, but I will reproduce the state to investigate further.
In my case: the battery ran all the way down, and the system appeared to be shut down, since the attached OLED display powered from the 3.3V but was off.
Reattaching USB got the device to start up, but the battery remained at 0% and would not charge.
To recover, I attached the battery to a 4v power supply w/ a 50mA current limit to slightly recharge the battery, and then reattached the battery to the system after the voltage rose to ~2.9v. At that point, the fuel gauge reported capacity and the battery would charge.
My one working theory is that the battery discharged far enough that the protection board on the battery kicked in and made the battery look like an open circuit to the PMIC, so charging would not restart.
@Pixelmatix Let’s let @Bdub know about the flash erasing.
We have advised a lot of people to run code that prevents the Electron from running once the battery SOC hits 20% or so. This helps keep the battery from reaching these lower voltages or the PCM on the battery from cutting the output off. This approach has been working on a solar power Electron for many months now to prevent a full Electron shut down.
Not ideal but it does prevent the full flash erase that some have seen.
@apullin I wonder if the power applied to charge the battery was somehow first consumed by the OLED causing the PMC on the battery to not kick out of shutdown mode?
My tests didn't show any difference with brownout configured vs not configured. I couldn't come up with data that shows it improves the situation in any way. It might be worth revisiting now.
Do you have a test setup that will consistently accidentally erase the flash on the Electron?
If so, can you share?
