Is anyone aware of a way for the AutoBoot to work with the usb power even when being powered by the battery. Example: The device was powered off abruptly due to power loss but now the device is connected to a battery that is charged. Now, when the device receives power through usb, can it be programmed to boot up? The autoboot only seems to work when the device is not connected to the battery.
I wrote this code so I can probably (a) figure out what is going on (b) fix it
Can you help explain the sequence a little more? This is as I read it, but I might be confused:
The device is connected via USB but NOT battery
The device powered off because the USB power disappeared
The device is then manually connected to the battery
The device does not automatically boot up
I gave this a quick test and it worked, so I'm not entirely sure I understand the scenario exactly.
I think you are saying that when connected to the battery, the autoboot never works - I tried this as well and it was ok, but I must be missing something
Some more questions:
1 cell, 3 or 4 cell particle battery?
Is the battery manually connected here, or something else used to connect it after the event? i.e. external circuit
Thanks!
Nick
(I'm available at nick @ particle if you need urgent help.)
( ed11b040 - thanks for emailing directly! I saw it instantly! Hope you don't mind, but I'll paste in the reply here for others to hopefully get value from as well. Thanks!)
Thanks so much for sending the video - super helpful. I’ve taken a close look, and I think I can explain what’s happening.
When the device first powers on, it evaluates everything power related that is attached to it - for example: is there a battery present, is USB connected, is a 5V input available, etc. If it does not detect a battery at power-on, the system enables an internal “battery emulator” mode. This is invisible externally, but it’s required because the Qualcomm chipset is fundamentally a battery-based (cell-phone-class) device and won’t operate correctly without one. So we fake a 4V battery feed that can't be charged and change the internal firmware to know about this battery so it doesn't apply current to it etc...
What’s happening in the video is that when the USB is unplugged, the system is effectively losing what it believes is its battery as when first booted, the battery wasn't detected. To detect, it uses a resistance on the 3rd pin of the battery connector (not voltage, so it can work with drained batteries). In addition, once the device has booted in a mode where a battery is present, the power system expects that battery to remain connected. The battery is used not only as an energy source, but also as a reserve for high current events and for managing the charging path. Disconnecting it during operation causes the power subsystem to fault.
The sequence that does work reliably is:
Battery connected first
Device powers on and detects the battery
USB can then be plugged/unplugged freely without issue
So for a deployed device with a battery, the battery needs to be permanently connected and present at initial power-on. After that, USB cycling is fine and the device will continue to operate normally.
Hopefully that clarifies what you’re seeing. I really appreciate you sending the video - it made the behavior immediately obvious.
Let me know if you want to dig further into this or test alternative configurations.
We want the device to aggressively try to keep booting and actually boot up whenever it's connected to USB-C external power from USB1. 3.7V battery will always be connected and never removed.
Sorry - had a family outing tonight but I can explain on email quickly!
You probably want the serial debugger - I can get one overnighted to you if you can send me your address? This will show you the exact behaviour of the device on the syscon and the linux terminal
If the battery is completely drained, when you reapply power, it can take 2-5 mins to charge to minimum viable voltage, which is something to consider. It's just like draining your cell phone - if the USB adapter can't power the device completely, it takes a while to charge the battery before it will boot out of the logo.
With this in mind, I have a dead battery I gave it a go from this state:
Battery dead but connected
USB-C power applied
Worked!
So then I did this:
Unplug USB-C
Battery shutdown happens after short period
Plug in USB-C
No boot!!!
So there is a bug! There are a few types of shutdown happening with (a) over heat (b) user space battery cut off (c) user shutdown - the one that is missing here is that there is a PMIC battery cut off happening that does not appear to log. It just kills power.
I have a reasonable idea how to fix this and will give it a go now.
My main question however:
what's the urgency on the timing here? I might be able to include a 1 liner hack that ignores all the logic and always boots as you suggested, but it will cause some fun things like 'shutdown' won't work and 'over heat' or 'battery' will get stuck in the bootloader. However, that might be enough for the time being?
@mrlambchop responding here just in case you haven’t received my direct emails from the last couple of days:
”Just to clarify on the ideal behavior:
Most preferred/ideal: Always boot on any power source (battery or USB) except for overheating and user space (assuming this means maxed-out space on disk; if not, please ignore this one).
Less preferred but workable: Always boot on any power source.
Apologises for the delay - if you check out our blog, you can see unfortunately it landed right at the wrong time of 'some org chaos' over here.
I am on this now and will turn around a solution before end of my day - its coded, its just hard to test as you need to simulate the dead battery condition
Sorry to hear about the org chaos, I wasn’t aware.
Getting something today would really help though! I totally understand on the testing environment needed… I do have a dead battery on my end to do final testing.
I know that you have it coded on Wednesday the 28th but if it is time consuming for testing, I have some ideas. To simulate the scenario repeatedly on my end, I have been using a linux based cpu stress testing tool called s-tui.
sudo apt install stress
Open s-tui
Then choose stress option
Battery drain in this configuration pretty high in case it’s taking a lot of time for draining.
