Brownout Condition on MSOM 6.2.1

Firmware
1

When upgrading from 6.2.0 to 6.2.1, I am seeing what looks like a brownout reset loop on my msom with my hardware. What happens is that the RGB LED turns on white for about a second before reseting and looping like this forever. This persists in 6.3.0 as well.

My hardware uses a bq24195l (pmic) a MAX17048 (fuel gauge), but neither of these ic's interrupts are connected to the msom. I know that causes some problems for me 6.2.1 as well, but those problems were with LTE connecting. (MSOM Connecting to Cloud Blocking Reprogramming - #11 by rickkas7)

This behavior seems to match what's described in the pmic notes, although my situation is different. I am using PMIC_DETECTION Power Manager feature.

image
image1387×331 46.5 KB

My design takes a 12V input which it uses to produce 2A of 5V, which then goes into the pmic. I can also supply power via the programming port, which also feeds into the pmic. If I use the 12V input and most usb ports, the unit performs a brownout loop, well except if I power with my m1 macbook's usb port (this fails on my intel mac).

My design also includes a backup 18650 battery (which I used to be able run without) and when I connect it to the board, it will boot, if the battery was sufficiently charged and it had passed the battery protection circuit. I usually need to send a charging pulse before the battery protection circuit allows the battery to connect electrically to the pmic, but the brownout loop is preventing that.

Our ILIM resistor for the pmic is 200 Ohms, so that puts our input current limit to > 2.5A. My setup for the pmic in firmware is:

    SystemPowerConfiguration conf;
    conf.feature(SystemPowerFeature::PMIC_DETECTION)
        .powerSourceMaxCurrent(3000)
        .powerSourceMinVoltage(3880)
        .batteryChargeCurrent(512)
        .batteryChargeVoltage(4200);
    int res = System.setPowerConfiguration(conf);

I ran this on 6.2.0, so I know it is being stored and loaded when I upgraded to 6.2.1.

This happens if I put the device in manual mode as well, so the device isn't even trying to connect to LTE. Battery charging is biased off in our design as well, so its not a load until the firmware enables it.

I have test points on my board so I can confirm my power upstream of the pmic are stable, except for the output of the pmic (bq24195L SW pin), which oscillates between 3 and 3.7V.

image
image1786×389 30.2 KB

My 3.3V power supply is downstream of the pmic and is oscillating between 3 and 3.3V. Its capable of supplying up to 1A.

image
image1502×381 32.7 KB

I am wondering if something changed in the device os that requires more power on boot up.

2

What other peripheral devices do you have on your board? On the Muon, there is a separate 3V3 supply for auxiliary peripherals (3V3_AUX) that power Qwiic, Ethernet, and LoRa because those items are enough current draw to prevent the M-SoM from booting at 100 mA. The 3V3_AUX supply isn't powered on until after the PMIC is reconfigured.

3

We have an sd card (which I can disable power to), usb host IC (max3421E) and rtc (ab1805). I know there is some negotiation the pmic performs to get more power from a usb source, but in my case, the source is an ACDC adaptor providing 12V to our system. That goes thru a 12-5V buck producing 2A for the pmic.

It seems like USE_VIN_SETTINGS_WITH_USB_HOST would solve my problem, but it does not.

4

I am seeing a brownout on the muon when supplying 12V into vin on 6.3.0, but not when I include a battery or connect with a usb c cable to my computer. Was the muon was designed to run on vin alone?

5

The problem is that the system browns out before it executes user firmware.

Yes, the PMIC uses DPDM to to negotiate a higher power limit based on the USB host, and it can happen while the system is still booting.

The Muon does run without a battery or USB, but that's why all of the peripherals had to be moved to a separate controllable power source. The AB1805 is on the MCU 3V3, however.

With the nRF52 it consumes a small enough power that this is rarely necessary; the only time you'd exceed the 100 mA limit is if you connected to cellular. The RTL872x, however, consumes enough power on its own that it's close to the 100 mA limit just booting with no radios operational yet.

6

Looks like I can replicate the behavior I am seeing on my hardware on the muon.

Here's what I have put on my muon running, would you be able to try it on 6.2.0 vs 6.2.1 and a Vin power source? For me its a brownout on 6.2.1 vs 6.2.0, which runs fine.

Also, I was not able to downgrade the device os from 6.2.1 to 6.2.0 without the battery connected. It started but no progress could be made. I was using particle update --target 6.2.0 after change the user firmware to do this.

#include "Particle.h"

SYSTEM_MODE(MANUAL);
SYSTEM_THREAD(ENABLED);

SerialLogHandler logHandler(LOG_LEVEL_INFO);
uint32_t loopTime;

void setup() {
    Serial.begin();
    loopTime = millis();

    Log.info("Setting up System Power Configuration");
    SystemPowerConfiguration conf;
    conf.feature(SystemPowerFeature::PMIC_DETECTION)
        .auxiliaryPowerControlPin(D7)
        .interruptPin(A7);
    System.setPowerConfiguration(conf);
}

void loop() {
    if(millis() - loopTime > 5000) {
        loopTime = millis();
        Log.info("loop");
    }
}

Here's what I got going into vin:

image
image817×1308 112 KB

7

I'll try to run the test on the Muon Wednesday or Thursday.

1 Like
8

I was unable to reproduce your problem with the Muon.

  • I used your firmware, except I changed logging to Serial1LogHandler and trace level:
Serial1LogHandler logHandler(115200, LOG_LEVEL_TRACE);
  • Device OS 6.2.1.
  • Powered from VIN at 12 VDC with a 2A current limit. No battery, no USB power.
  • Device booted normally and is drawing 0.069A at 12V. See log below.
  • It also worked at 9V.
  • It did not boot at 6V, however.
0000000754 [system] INFO: Device xxx started
0000000817 [hal] INFO: WiFi KM0 firmware initialization started   result=0 (RAM start=10006000 end=1001a000)
0000000822 [hal] INFO: WiFi KM0 firmware initialization completed result=0 (RAM start=10006000 end=10013fa0 reserved=00005000)
0000000843 [hal] INFO: rltk_wlan_set_netif_info: 0, 94:94:4a:05:22:60
0000000974 [hal] INFO: WiFi on
0000001218 [sys.power] INFO: Enable auxiliary power
0000001323 [hal] INFO: WiFi off
0000001944 [system.nm] INFO: State changed: NONE -> DISABLED
0000001967 [comm] INFO: channel inited
0000001969 [app] INFO: Setting up System Power Configuration
0000006970 [app] INFO: loop
  • Also tested with 6.2.0 and that worked as well.

It's not clear to me why the Muon is not working for you.

However, I do think the 5V supply to the PMIC may be a factor on your real board. On the Muon, the PMIC is supplied at 9V, even when powered by USB. This is done using USB-C PD to change the USB voltage, and is also why you can't power the Muon with a USB-A to USB-C cable, since USB-2 can't change port voltage.

It is also why when using the old M.2 evaluation board, which has USB-2 Micro USB, you need to power it by battery or the barrel connector at 9V or 12V when using the M-SoM. The M-SoM won't boot in that board with the PMIC powered at 5V from USB without a battery.

9

I went back to my hardware and started installing the different commits between 6.2.0 and 6.2.1 using build script 1.13.0. I was able to confirm device os update by calling System.version() and adding an additional hardcoded log of the git hash:
ex

// wiring/inc/spark_wiring_system.h  
    String version() {
        LOG(INFO, "3c00c1116045da3086b1ddb651c01f1ab84bcbcf"); // I added this
        SystemVersionInfo info = {};
        info.size = sizeof(SystemVersionInfo);

        system_version_info(&info, nullptr);
        return String(info.versionString);
    }

This resulted in an additional log whenever I called System.version():
0000182306 [app] spark_wiring_system.h:801, SystemClass::version(): INFO: 3c00c1116045da3086b1ddb651c01f1ab84bcbcf, confirming the update.

So starting from 6.2.0, I was able to flash and run every commit I tried until the actual 6.2.1 release commit. This includes 3c00c1116045da3086b1ddb651c01f1ab84bcbcf.

image
image1640×579 66.6 KB

I can get my device to power on with the 6.2.1 (0da034f62ca5fa15bb2191c590685d33f535651a) release commit, at least until it tries to update the bootloader #0. Actually my device was just fast blinking cyan for a long time on the last commit, so I ran particle update --target 6.2.1.

image
image985×1164 119 KB

It is after the bootloader updates, that my device enters its brownout loop.

What were the changes between bootloader version 9 and 10?