PMIC calls now catastrophically crash Boron due to Particle software update

This is a frustrated continuance of this thread (Boron found dead and irrecoverable-without-LiPo after 1-month of normal use - what happened?), now that I know exactly what the problem is, with shared elements of this thread (Boron - RGB Led Flashing White - Fixed) and this thread (1.3.1-rc.1+ change to Boron solar charging (via VUSB) behavior).

Notice how recent this all is. Particle screwed up the firmware in an allegedly beneficial “update”, to which I spent time and effort updating my remote devices.

Now Particle’s software “update” has cost me yet another 3-hour-both-ways drive to remote site, and will require yet another one just because of one line of previously functioning code.

While I’m happy about the recent cellular fix, it has now introduced the laughable situation of creating yet another catastrophic disaster incapacitating my usage of the device for remote solar powered tracking.

I have now consistently reproduced that any call in setup() to PMIC controller in Boron 1.4.0 will crash the MCU, causing it to flash white for a second and then go totally dead and irreparably unless a human holds the buttons right to put it into safe mode. This was working perfectly on older OS versions.

This code invariably causes Boron to instantly crash:


PMIC pmic;
void setCharge() {
  pmic.setInputCurrentLimit(900) ;

void setup() {
    Particle.publish("ON_TIME", String::format("%d",, NO_ACK);
bool sent = false;
void loop() {
   if(Particle.connected() && (!sent)) {
       sent = true; Particle.publish("On", "On");

Commenting out the setCharge() invariably prevents Boron from auto-crashing.

My questions are as follows:

  1. Why didn’t Particle disclose in their V1.3.1 or 1.4.0 updates that it would cause previously functioning code to totally crash, and require a minimum of 12 hours (3 hours both ways, x2 for reinstallation) of driving on my part?

  2. Will Particle reimburse me for the hours of my time it wasted by publishing an update which caused previously functioning code to totally crash?

  3. Will Particle ever re-enable usage of the PMIC functions without crashing the device, or will we be no longer able to use Boron in remote solar powered environments unless we downgrade to 1.2.1 and older, in which case it will catastrophically fail to ever reconnect and become useless for the separate and distinct reason of the now-fixed cellular issue?

  4. Does Particle still sell the Electron unit? From what I see, it is the only product Particle has ever sold which is actually usable and stable in a remote tracking environment. At this point I am willing to swallow the increased 3G power consumption versus a fake LTE board that won’t actually work for any permanent solution.

Thank you.

1 Like

@Paul_M, I certainly understand your frustration.

As I’ve expressed before: allowing System Power Manager to blindly change setInputVoltageLimit to (3880) despite the User’s PMIC settings is detrimental to Solar Powered Borons.

I noticed that the temporary work-around included a delay (that you are missing) after the detachInterrupt from This post. Maybe that will help? :crossed_fingers:

void setup() {
    // Delay for up to two system power manager loop invocations
    // Change PMIC settings
    PMIC pmic;
    // your specific settings here

Thank you very much for calling the delay to my attention. Yes, that does seem to enable me to make PMIC calls without triggering the new, unannounced, firmware-update-related catastrophic crash.

Now to actually test recharging behaviors with the new firmware.

I contacted Particle and am very content with the kind support I received including preparing a temporary Electron-based workaround.

Any official word from Particle on these new issues, what should be done for now, and what will be done/fixed in the future?

I’m wondering the same thing. The nature of my work makes it so I deep-dive into this stuff only once every few months. So without following the forums and release notes diligently from now to eternity, how am I going to know which upcoming firmware is safe to use for a cellular+solar Boron solution?

I’m not a DevOps guy, but once the fix is implemented would it be feasible to work backwards through the alleged ‘production releases’ 1.3.1 and 1.4.0 and apply the fix to those?

I’m usually just a ‘latest and greatest’ kind of guy, but like you (with a 3 hour drive to match), this clusterup has me rethinking that approach!

1 Like

could be beneficial to future development if you change your methodology to include a local device for testing purposes to allow you to fully test the device against any firmware updates prior to making any changes to the remote device. i would imagine if you continue to use a remote device for testing of new firmware updates the possibility exists for future disappointment. good luck. additionally, since you are considering the electron you might want to research the low battery/allowing battery to fully drain firmware corruption issues. i’m not positive that this problem has been fully corrected.


Hey folks – thanks for sharing your concerns…am working with the internal team to pull together an update and will post it here ASAP. Apologies for any issues you’ve experienced in the meantime.


Today, I tried to confirm that the workaround detachInterrupt(LOW_BAT_UC) returns the PMIC to previous Charging Performance since I have extensive test results for Boron Charging.

While the workaround does enable charging, It Does Not compare to previous results.
1.4.2 fails miserably when compared to the actual PMIC performance under earlier firmware.
Both Solar and Utility Powered when using the USB connector.

Since the Li-Po Charging issues are Chronic verses Acute, the typical user testing of the recent firmware before each user deploying to field devices didn’t catch it.
More testing should be performed for all Input conditions before the next significant change to System Power Manager :wink:. It has far reaching implications IMO.

The Device Update Thread doesn’t mention how to downgrade a Gen3 device from 1.4.2 (only Gen2).
Any suggestions to safely downgrade Borons?

Thanks Will.

Thanks for sharing. This is disappointing. I assumed 1.4.2 fixed this (haven’t tested yet), and I think it did fix the instant crash issue in my OP, but it is important to know the charging issues - newly introduced by software updates - persist.

Regarding downgrading, I have in the past performed highly-useful (given the current Boron firmware status) downgrading by simply flashing the old OS binary over particle cli usb in DFU mode.