Repository navigation
v0.90
Fixes a bug that left a companion board on the GPIO header unpowered whenever the Flipper was plugged in.
If you use a board on the header (ReksLab Tri-Board, CaracalDB, or anything without its own USB) and you work with the Flipper connected to a computer or a charger, this one is worth taking.
What was wrong
The app raises the header's 5V rail when the companion does not answer, but it skipped that entirely whenever USB was present. The reasoning in the code was that with VBUS present the header is fed from it, so a board that needs 5V already has it.
That isn't true. The Flipper does not pass VBUS through to pin 1. That rail comes from the charger's boost either way, and asking for it works fine while plugged in.
The rail is also off after every power cycle. So the board stayed dead, scans reported ESP 0/s with no frames, and nothing in the app would bring it back until you unplugged the Flipper.
Measured on the bench, tethered: header dead, companion silent, and a single power 5v 1 on the CLI brought the board straight up on the same cable.
What changed
It attempts the enable now instead of standing down. If the charger genuinely refuses while drawing from VBUS it re-arms quietly and comes up the moment you pull the cable, rather than showing a "5V refused" error on healthy hardware. On battery a refusal is still reported as a real fault.
Verified by forcing the rail off, opening a scan, and watching the board come up on its own inside the grace period at 13 frames/s.
Breaking changes
None.
Upgrading
Just the .fap. No need to reflash the companion, nothing on that side changed.
| Your firmware | Download |
|---|---|
| Official (OFW) | flipdeflock.fap |
| Momentum | flipdeflock-momentum.fap |
| Unleashed | flipdeflock-unleashed.fap |
| RogueMaster | deflock.fap |
If you are coming from v0.87 or earlier, see v0.89 for the drone detection and redacted exports that landed there.
Full Changelog: v0.89...v0.90