Issue: When I was implementing the new charging code on my LTE boron:
PMIC pmic; // retained the PMIC class to still have the ability to use pmic.disableCharging(); for temp control
SystemPowerConfiguration conf;
void setup(){
conf.powerSourceMaxCurrent(1500)
.powerSourceMinVoltage(5080)
.batteryChargeCurrent(1024)
.batteryChargeVoltage(4112);
System.setPowerConfiguration(conf); // retains these settings
}
void loop{
bla bla bla;
}
the boron would only charge my lipo to around 3.97 volts. This is in mostly direct sunlight all day in Colorado. I had the battery voltage set via conf.batteryChargeVoltage(4112); so I should have been hitting around that number. Here is the graph:
Can anyone explain why the addition of PMIC pmic; would affect the charging behavior in any way? I never made a pmic call except for the declaration. I was planning on using it later in order to disable the lipo from charging below 0°C.
Hopefully I’ve just messed up somewhere, but if PMIC pmic; really is causing this problem that means I can’t use pmic.disableCharging();. Whats the alternative?
Also, the boron is on a 50 minute timer via TPL5111/EN, so the device is being reset every time it wakes up.
While there might be other reasons for SammyG one common reason for this would be to prevent charging when it's too hot or too cold - LiPos don't like being charged under these circumstances.
Would be great if that were a default feature facilitating the nRF52840's internal temp sensor (obviously allowing to be overridden)
I need this functionality as well. This is an unanswered question with the new PMIC scheme. I get around this by configuring the power manager to be turned off.
@SammyG@hwestbrook@Backpacker87
Thanks for the answer, I suspected it - but wanted to confirm. I live in a much more stable climate, so it’s not a problem here.
I have an answer
The new power manager does not have a way to disable charging at the moment - I’m logging a feature request for this tomorrow.
For now though, the PMIC pmic(); is the only option.
Where you are declaring it is the issue - it it locking up the PMIC to a thread and not releasing it. Thus the Power manager can’t run properly.
If you declare it in the loop when disabling charging, it should work fine.
So you’d call:
PMIC pmic(true); //Calling it with true locks it to the user code
pmic.disableCharging();
When you want to give control back to the power manager: pmic.unlock();
In my testing w/ RC1, the pmic.disableCharging() Call worked correctly, when using the New API.
Then only real difference that I see from the OP’s code was I had additionally:
conf.feature(SystemPowerFeature::PMIC_DETECTION) // For platforms with external PMIC/FuelGauge (e.g. BSoM),
conf.feature(SystemPowerFeature::USE_VIN_SETTINGS_WITH_USB_HOST)
But after an EN Pin Shutdown, you must re-check the enclosure Temp on WakeUp to evaluate if you need to disable Charging again (doesn’t persist after an EN Pin Shutdown, obviously).
I was under the impression that lock and unlock were reserved for multithreading applications and are not designed for this type of thing. I want to keep the Boron (or Electron) from reenabling charging for hours at a time. Is this safe for that use case?
The lock feature in PMIC only prevents simultaneous access from the system thread and system power manager and your user calls to the PMIC. If you don’t lock, there’s a possibility that the system and user calls will be interleaved and not have the desired effect.
You want the lock in a small scope, even surrounding it with {}.
{
PMIC pmic(true); //Calling it with true locks it to the user code
pmic.disableCharging();
}
Don’t lock across a long period of time, like the whole time charging is disabled.
I have experienced a similar problem with PMIC under 1.5.0 I power the processor with 5v from VUSB and do not have a LiPo battery connected. The reason is that the device is only used for a 20 min session once or at most twice a day. The power is switched on with a momentary button and electronic switch and is turned off automatically using the electronic switch.
Under OS 1.4 I used pmic.disableCharging to avoid the processor failing to start - it worked a large proportion of the time but occasionally the yellow charging light would come on and the processor would freeze. It needed to be kicked into action by turning power off and on or a reset operation. This seemed to only happen after the unit had been off for an extended period. I have considered putting the processor to sleep rather than powering it down but this would require the addition of another button to wake it up.
Under OS 1.5 this has become a hard feature. Whenever I power it up the yellow charging light comes on and the processor can only be set working by hitting the reset button. pmic-disableCharging appears to have zilch effect.
I would appreciate your advice as this completely negates the suitability for my application.
@OziGreybeard, 1.5.0 allows you to completely disable the new DeviceOS System Power features.
Something similar to this might get you started:
SYSTEM_THREAD(ENABLED);
PMIC pmic;
SystemPowerConfiguration conf;
STARTUP( turnOffPowerFeature() );
// see https://community.particle.io/t/boron-solar-charging-with-1-5-0-rc1/54680/10?u=rftop
void turnOffPowerFeature() {
conf.feature(SystemPowerFeature::DISABLE);
System.setPowerConfiguration(conf);
pmic.begin();
// all of the PMIC calls that you want go here
pmic.disableCharging();
}
void setup() {
}
void loop() {
}
@Rftop Sadly I spoke too soon - it improved but is still faulty.
The system had been running with power from the computer and continued to start up repeatedly without hanging. Hence my message.
However, when I left it off for a period it refused to start without a reset. It’s almost as if there is some storage effect that allows the processor to restart when it has been on but fails if it has been off for a while.
Hence it is better than it was but is still inadequate. Given the intended use this would mean that the patient would need to switch the unit on and off twice to get going.
@OziGreybeard I’m under lockdown for the moment and won’t be able to properly test anything until the first week of May.
What I do see in @Rftop’s code is that the PMIC pmic; is being called right up top, it should be part of the function and not called globally.
Try this:
void turnOffPowerFeature() {
conf.feature(SystemPowerFeature::DISABLE);
System.setPowerConfiguration(conf);
PMIC pmic(true);
pmic.begin();
// all of the PMIC calls that you want go here
pmic.disableCharging();
}
Could you provide clear and comprehensive code snippets for turnOnCharging() and turnOffCharging() that is expected to work in the new 1.5.0 which we can use to enable/disable VUSB solar charging based on temperature? I’ve been patiently waiting for Particle to fix these issues and was very happy when 1.5.0 came out thinking that they may now be fixed, but there is an indication above in this thread that that might not be the case. I repeat the sentiment above that this is all useless if we can’t dynamically enable/disable charging. Once we can do that, the Boron becomes VERY useful to me.
If you gave me clear turnOnCharging() and turnOffCharging() functions, I would happily test them and use cloud functions to go 2-days on 2-days off, etc. and make sure the results are consistent and stable. The last part is key because I was having Borons crash simply from valid PMIC calls in the old versions.
