Entire Particle Boron platform currently INOPERABLE due to solar/PMIC/power/battery issues

Firmware
1

I have purchased many Borons.

Please see: Boron not charging while sleeping (Solar) - #5 by Paul_M
Boron 1.4.2 battery charging issue
Boron LED flickering after some time and never wakes up again - #5 by T1mS
PMIC calls now catastrophically crash Boron due to Particle software update - #6 by will
Boron found dead and irrecoverable-without-LiPo after 1-month of normal use - what happened?
1.3.1-rc.1+ change to Boron solar charging (via VUSB) behavior - #8 by epbwhiz

Please see the multitude of recent threads in the past month which have addressed this comedy of errors without any sufficient official response from Particle.

I come with a humble request:

I challenge you to tell me exactly how to use a Boron with the newest firmware version in an environment where:

  1. I have a 6W solar panel into VUSB
  2. I have my Boron on 24x7 without Sleeping (even though I should be able to use Sleep but I understand that is currently causing a separate firmware-related disaster; see thread above)
  3. I have a 3.7V LiPo attached to Boron
  4. I need to programmatically disable/enable charging the LiPo based upon temperature reading during the main program loop (because you can't charge them under 32F, but only discharge, is my understanding)

It would take hours and hours to go through the insane amount of confusion, errors, bugs, conflicting information, workarounds, crashes, etc. all part of the past two-month comedy of errors introduced in the new corrupted firmware which destroyed everything power/charging on the Boron.

As much as I love Particle and desperately want to stay a loyal customer, I need to be able to accomplish the above incredibly simple task which is absolutely ridiculous to be a problem to implement.

Please give direct steps to make this happen, showing what exact code/PMIC calls we are supposed to make, and I then I will implement that, and report back if there are any issues.

I am seeking to prove the hypothesis that the entire Boron product has been completely ruined in its usefulness by recent terrorist firmware "updates" by Particle and hope to be proven wrong in this theory.

If Boron needs to be plugged into the wall and can't be operated in a solar/LiPo environment, then you probably have WiFi wherever you have wall-power, and the entire Boron is totally useless versus a $2.00 ESP8266 from China.

DISCLAIMER: The following thread is not sufficient for my purposes, because it is Electron-only, and does not betoken any awareness of the recent firmware disaster and mysterious, crashing behavior relating to these PMIC calls on newest Boron firmware:

1 Like
2

Hi Paul,
What amount of current are you pulling from the L7805?

3

I have no idea but it is just normal usage with zero external things attached. Testing with bare Borons and Particle firmware. How could high current consumption be responsible for some versions of the Boron entering the nonresposive crash state upon PMIC calls?

4

The L7805 has up to a 2V dropout, depending on current draw, and it is not particularly efficient.

There is a voltage limit on the power source being used that is set on the PMIC, so supplying it with a voltage that is too low can cause issues.

I think the best bet would be to open up a ticket on Zendesk so we can walk through the issue with you to identify the cause.
Particle Zendesk
I’ll grab the ticket and we can sort this out.

5

Hi @Paul_M - just to follow up, please file a ticket on this; I have some time tomorrow to get on a call with you to talk through everything.

1 Like
6

Done; many thanks. I would definitely describe over the phone tomorrow how valid PMIC calls are causing a certain 1.4.4 Boron, but not another, to crash. I detailed this also in a recent email response to Nathan Wang. I anticipate this conversation will be useful both for you and for me. Thank you!

7

Let us know if this makes any progress, right now I’m toying with remaking my parent board for our boron devices to use a third party charging circuit (more cost, more complexity). Charging on mine seem to be something just shy of zero at the moment.

8

Any update?

1 Like
9

Engineering is looking into the issue. We are still gathering data and will assess the situation to find a solution. The timeline is not set in stone, so I cannot promise a quick resolution. Particle is closed for the holidays, except for our core support.

Anyone else experiencing the same issue must please submit a ticket to Particle Support with as much information as possible regarding your setup. (Voltage at VIN/VUSB, Battery capacity (mAh), power source, current draw, etc.)
Ask that I (Chris) take the ticket so I can keep track of all the issues.

2 Likes
10

Hey everyone. Just wanted to give an update that we have a PR which will be included in the next DeviceOS release that changes and adds a few things:

  1. We’ve reverted the changes to the default PMIC settings we use when powered by VIN. These are now again 3.88V min, 900mA max for the PMIC to enter DPM mode and reduce current consumption.
  2. When powered by USB host or USB-compliant adapter, the current limit is automatically negotiated with the other side and voltage input limit is still set to 3.88V.
  3. Another addition is a higher level power configuration API allowing to notify the system about the expected PSU parameters. These settings are persisted and work correctly even without the application running (e.g. while the device is in safe mode). See ‘Example App’ section for the example usage.
  4. The PR also adds a couple of methods to query current power source, battery state and state of charge more easily. See ‘Example App’ section as well.

In general, if your power source cannot go below 5V and can supply maximum 1A of current, all that is required is the following code block which will store these settings in the persistent storage:

    SystemPowerConfiguration conf;
    conf.powerSourceMaxCurrent(1000).powerSourceMinVoltage(5000);
    System.setPowerConfiguration(conf);

This can be run in STARTUP() block as well. There is no harm in keeping it in the application forever, as the settings will only be overwritten if there are any changes to the already stored configuration.

As this is a feature that for now only exists in the form of the PR, one for now may use Workbench deviceOS@source feature to build out of ch42646/power-management branch.

4 Likes
11

Thank you so much for your attention to this and for, in general, the excellent support I have received from Particle. (Shoutout to Chris for giving me a phone call to collect more info about this issue). While I haven’t gone through the effort to read fully and understand what your PR does, I will be sure to test it when it comes out and reevaluate the accuracy of this thread’s title. I will share also that I have one Boron that is working perfectly in this area, using the current non-ideal workarounds, and another which does not appear to be able to stably work in such a way. I will simply wait for your next update before spending more time on this. Thanks.

2 Likes