Boron Solar Charging with 1.5.0 PMIC issue

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:

After a while later, I tried commenting out the following line: PMIC pmic; and ran the test again.

Now the device charged the same battery to 4.07 volts, more or less as expected. Here is that 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.

1 Like

The new power configurator supercedes the PMIC. You are attempting to use two methods to do the same thing.

Just out of curiosity - why are you attempting to stop charging? I’m enquiring as to what the correct call would be.

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) :wink:


I just saw it in the OP

3 Likes

Yes @ScruffR is correct. I need to disable charging based on temperatures… both too cold and too hot.

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.

I also need this functionality for disabling charging based on temps.

I have a TMP36 temp. sensor on the board to determine the enclosure temperature and disable charging if it exceeds 113F.

It would be amazing if this was a default feature utilizing the internal temp. sensor.

Update: I found this post from a bit back showing that the onboard temp. can be accessed.

1 Like

@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 :slight_smile:
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();

Let me know if that works for you.

1 Like

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.

2 Likes

OK, so if I disable charging in this way will that disableCharging setting “stick”?

It seems like the power manager will reenable charging either after wakeup or after a PMIC watchdog.

So

{
  PMIC pmic(true); //Calling it with true locks it to the user code
  pmic.disableCharging();
}

can be called to disable charging. Cool!

Now after the device is reset, the following code:

SystemPowerConfiguration conf;

void setup(){

  conf.powerSourceMaxCurrent(1500)
      .powerSourceMinVoltage(5080)
      .batteryChargeCurrent(1024)
      .batteryChargeVoltage(4112);
  System.setPowerConfiguration(conf); // retains these settings
}

will function as normal?

It should, yes :slight_smile:

@no1089

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.

Thanks.

@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()   {
}


1 Like

Thanks @Rftop. That did the trick nicely.

@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.

@no1089 Can you offer any insight into this behaviour?

@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.

3 Likes