[sensei-hacker]

Problem

With a logic condition using operation 22 (Override Arming Safety) active, failsafe DROP disarms and sets ARMING_DISABLED_FAILSAFE_SYSTEM, then tryArm() re-arms about 0.1 s later because the override bypasses every arming-disabled flag. Motors stay at their last value (found on a boat with reversible motors).

Fix

In tryArm(), the override no longer applies while ARMING_DISABLED_FAILSAFE_SYSTEM is set. The flag clears through the existing path (RX good for 30 s and arm switch off). Docs row for operation 22 updated.

Testing

SITL: failsafe_procedure=DROP, MSP receiver, LC logic 0 1 -1 22 0 0 0 0 0, link loss with the arm switch still high. Before the fix the FC reported ARMED together with ARMING_DISABLED_FAILSAFE_SYSTEM; after, it stays disarmed.
Also confirmed on hardware

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Prevent arming-safety override from bypassing failsafe lockout

🐞 Bug fix 📝 Documentation 🕐 10-20 Minutes

AI Description

• Prevent Override Arming Safety from re-arming a craft after failsafe DROP disarms it.
• Preserve existing override behavior for other arming restrictions and document the failsafe
 exception.

Diagram

graph TD
  F["Failsafe DROP"] --> L["Lockout flag"] --> T["tryArm"] --> D{"Override usable?"}
  O["Logic override"] --> T
  D -->|"Lockout set"| S["Override blocked"]
  D -->|"No lockout"| A["Override permitted"]

Loading

High-Level Assessment

Keep the exception in tryArm: it protects the failsafe lockout without changing when failsafe clears the flag or broadly restricting other arming paths. A global prohibition on arming while the flag is set would have a wider behavioral impact.

Files changed (2) +4 / -2

Bug fix (1) +3 / -1

fc_core.cBlock logic-condition override during failsafe lockout +3/-1

Block logic-condition override during failsafe lockout

• Requires ARMING_DISABLED_FAILSAFE_SYSTEM to be clear before the logic-condition override can satisfy tryArm's arming check. Other override behavior remains unchanged.

src/main/fc/fc_core.c

Documentation (1) +1 / -1

Programming Framework.mdDocument the failsafe exception to Override Arming Safety +1/-1

Document the failsafe exception to Override Arming Safety

• Clarifies that operation 22 cannot override the arming lockout following a failsafe disarm.

docs/Programming Framework.md

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can move or hide resolved findings to focus on what still needs action

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[github-actions]

RAM / Flash usage vs. base commit 5927460 — commit def4a0a

Target	Flash Δ	RAM Δ
MATEKF405	±0 B (±0.00%)	CCM: ±0 B (±0.00%) RAM: ±0 B (±0.00%)
MATEKF722	±0 B (±0.00%)	ITCM_RAM: ±0 B (±0.00%) RAM: ±0 B (±0.00%) TCM: ±0 B (±0.00%)
MATEKF765	±0 B (±0.00%)	DTCM_RAM: ±0 B (±0.00%) SRAM1: ±0 B (±0.00%)
MATEKH743	+16 B (+0.00%)	D2_RAM: ±0 B (±0.00%) DTCM_RAM: ±0 B (±0.00%) ITCM_RAM: ±0 B (±0.00%) RAM: ±0 B (±0.00%)

See RAM/flash optimization guide for techniques to reduce usage.

[github-actions]

Test firmware build ready — commit def4a0a

Download firmware for PR #12161

251 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.