Does it behave differently if you apply the load AFTER power up?
In my case, no. It can happen regardless of when the load is applied.
I havenāt been able to correlate the time-to-failure with any factors, such as hot start vs. cold start. The issue often appears between 5 and 15 minutes after boot/load applied, but it seems quite random; Iāve had it happen immediately after applying the load, or never (left it overnight).
Is it possible this is not a new issue? Here is a thread in the archive over at ardupilot.org, referencing low/no voltage on peripherals using a similar bq2431x component, but i assume back on legacy pixhawk and the user reports a crash, so maybe it was physically damaged:
ā¦ And thereās another current thread over there in the /hardware/pixhawk section with no power:
For what itās worth, we have never experienced this issue before (100+ units). It only started happening recently, and on multiple units, so it seems to be a new issue to us.
The PSM seems to start regulating even on low currents if the reset was not done properly.
A 300mA load is enough on long time periods (15-20mins).
Do you have varying load on the power bus? Using constant resistive load makes this issue quite repetitive and easy to replicate.
Issue found, Tridge is doing a patch for this as we speak 
Once he has a firmware, are any of you guys willing to bench test it?
1 Like
Great, thanks. I will start testing it.
Not yet, but soon I will have the equipment to start making more scientific measurements. Will test old and new firmware with various loads.
1 Like
PSM is reset properly now on every reboot. The Power enable is pulled high for 107 ms, should be 100 ms? However that should not be a problem?
PSM works now like it is specified to work.
2 Likes
Awesome!
How ironic is it, that making code more efficient can cause an issue like this!
Glad itās better
My experiments:
Attached a load that pulls ~0.8A on the I2C 2 port. Ran trials that consist of powering the Cube Black, waiting ~5 minutes for the current to be limited (or not), then un-power the Cube.
Copter 3.5.7 NuttX: Problem appeared 37/50 trials.
Copter 3.6.2 ChibiOS (and later): 0/30 trials.
Copter 3.6.8 with above PR: 0/10 trials.
It seems that, at least for this specimen, the problem had already been solved by Copter 3.6.x, I guess it gets hidden by different timing on ChibiOS boot, so I canāt really test the PR with this particular Cube. We have blue cubes on hand, Iāll see if I can reproduce it with them.
To me, the mystery is why this suddenly started happening. Weāve flown 3.5.7 since its release and only had this issue appear lately, which suggests a hardware change. It wonāt be an issue once we finish migrating to 3.6 (assuming the PR fixes it), but the sudden and inexplicable onset was a bit jarring. Glad @Morso was able to dive into it deeper than I could.
The change is the bootloader.
Is this new bootloader included in 3.6.9? If not - How does someone install it?