.pr_agent_accepted_suggestions - iNavFlight/inav GitHub Wiki

RP2350 supplies no-op implementations of the CMSIS DSP functions used by dynamic gyro notch analysis. Although the target disables the filter only by default, users can re-enable it and receive silently invalid filtering.

Either provide functional ARMv8-M-compatible DSP implementations or compile USE_DYNAMIC_FILTERS out for RP2350 so the unsupported setting and execution path cannot be enabled.

• src/main/drivers/system_rp2350.c[220-287]
• src/main/target/RP2350_PICO/target.h[150-175]
• src/main/target/RP2350_PICO/config.c[24-31]
• src/main/flight/gyroanalyse.c[72-89]

Adding an item changes the stride of each row in persisted item_pos[OSD_LAYOUT_COUNT][OSD_ITEM_COUNT]. Because the registered PG version remains 3, old four-layout payloads are copied as a flat prefix into the new shape and alternate layouts become misaligned.

The generic PG loader only performs a size-limited memcpy when versions match; it does not migrate two-dimensional arrays. Either bump the layout PG version so incompatible data resets safely, or add an explicit migration that copies each old layout row into the matching new row and initializes the Terrain AGL slot.

• src/main/io/osd.h[382-383]
• src/main/io/osd.c[235-236]

The sibling-branch cache survives ordinary enum members, causing a later opposite-polarity conditional to reuse a stale numeric base even though the two blocks are not adjacent alternate branches.

Only an immediately corresponding opposite-polarity sibling should reuse the closed branch base. Parsing any intervening enumerator must invalidate the closed frame at that nesting level; add regression coverage including an intervening explicit assignment.

• docs/development/msp/gen_enum_md.py[107-114]
• docs/development/msp/gen_enum_md.py[262-297]

MSP2_INAV_SET_GEOZONE_VERTEX accepts a circular-zone payload without the required four-byte radius, mutates the center, and reports success.

Polygon updates require a 10-byte prefix, while circular updates require that prefix plus a 4-byte radius. Preserve lenient acceptance of bytes beyond the known complete encoding, but reject circular payloads shorter than 14 bytes before mutating vertex state.

• src/main/fc/fc_msp.c[3922-3936]

The pruning query attempts to match a one-line anchored regex against the complete multi-line release body, causing releases created by this script to be omitted.

Extract and validate the first body line, and ensure malformed notes still emit a record under the fallback branch group rather than disappearing from the stream.

• .github/scripts/publish-size-baseline.sh[74-76]
• .github/scripts/publish-size-baseline.sh[87-92]

The pruning AWK program only considers retained tags when producing deletions and loses every tag outside the per-branch keep set.

Track every input tag, retain only the newest configured count per branch and then the global count, and print every input tag absent from the final keep set.

• .github/scripts/publish-size-baseline.sh[99-120]

The new derivative-on-measurement path differentiates wrapped COG directly. Crossing 0°/360° therefore creates an artificial full-circle delta and a large D-term roll correction.

navHeadingError is wrapped safely, but actualState.cog is represented as a wrapped angular value. Preserve derivative-on-measurement while making the measurement delta wrap-aware, for example by maintaining a continuous/unwrapped COG value or adding an angular-difference-aware PID input path; reset that state whenever the navigation PID is reset.

• src/main/navigation/navigation_fixedwing.c[555-561]
• src/main/common/fp_pid.c[60-73]
• src/main/navigation/navigation_pos_estimator.c[742-752]

The WS2812 RAM figures assume 2-byte DMA elements even though the supported timer DMA-safe type is 4 bytes.

The full array has 3,115 elements and the proposed 2×4-LED circular buffer has 192 elements. Keep the stated byte counts consistent with the guide's later requirement to use timerDMASafeType_t.

• docs/development/ram-and-flash-optimization.md[52-55]

resolutionType_e is a wire-protocol enum (sent as a raw byte via MSP_DP_OPTIONS). This PR updates its explicit values, but the committed enum reference artifacts under docs/development/msp/ still document the old ordinals, causing protocol documentation drift.

The repo contains auto-generated enum reference files (inav_enums.json, inav_enums_ref.md) produced by docs/development/msp/gen_docs.sh / gen_enum_md.py. These should reflect the updated resolutionType_e members and values (including the newly reintroduced HD_3016=2).

• src/main/io/displayport_msp_osd.c[64-73]
• docs/development/msp/inav_enums.json[3300-3306]
• docs/development/msp/inav_enums_ref.md[4824-4834]

• Regenerate/update docs/development/msp/inav_enums.json and docs/development/msp/inav_enums_ref.md so resolutionType_e matches the new wire values:
• SD_3016 = 0
• HD_5018 = 1
• HD_3016 = 2
• HD_6022 = 3
• HD_5320 = 4
• Prefer running the documented generator (docs/development/msp/gen_docs.sh) and committing the updated artifacts, rather than hand-editing.

In-flight auto-close paths call cmsMenuExit(..., CMS_EXIT), but cmsMenuExit() does not dispatch onExit callbacks for CMS_EXIT. Menus that rely on onExit for cleanup (e.g. OSD layout preview override) can leave that transient state active after an emergency/timeout close.

• In-flight main menu includes the OSD submenu (cmsx_menuOsd), which can enter menuOsdElements that sets an OSD override on enter and clears it on exit.
• Safety close / inactivity close uses CMS_EXIT, not cmsMenuBack(), so no stack unwinding happens.

• Ensure auto-close (safety/timeout/switch-off) triggers the same cleanup as backing out of menus:
• Call currentCtx.menu->onExit(...) if present.
• Optionally iterate menuStack[] and call onExit for each stacked menu (similar to the popup-save traversal) to guarantee cleanup.
• Keep the “no EEPROM save/reboot while armed” restriction intact.
• src/main/cms/cms.c[908-944]
• src/main/cms/cms.c[1443-1457]

Calling batteryInit() while armed resets live battery runtime state (batteryState, cell count, and voltage thresholds). This can transiently change behaviors that depend on those values (notably throttle VBAT compensation which uses batteryFullVoltage).

The CMS battery menus already write settings directly; they only need to refresh derived thresholds/state, not reset battery presence.

• Replace batteryInit() (armed path) with a new targeted refresh that:
• recomputes batteryFullVoltage/batteryWarningVoltage/batteryCriticalVoltage based on current batteryCellCount and current battery profile, without forcing batteryState = BATTERY_NOT_PRESENT.
• avoids transiently zeroing values used in the mixer.
• If a new battery API is needed, implement it in sensors/battery.c and expose via sensors/battery.h.
• src/main/cms/cms_menu_battery.c[60-68]
• src/main/cms/cms_menu_battery.c[100-109]

docs/Telemetry.md says MAVLink is transmit-only, but the implementation processes inbound MAVLink messages. This is incorrect documentation and can lead users to wrong configuration/expectations.

The telemetry MAVLink code contains an explicit receive loop and dispatches received message IDs.

• docs/Telemetry.md[205-210]
• src/main/telemetry/mavlink.c[1388-1433]
• src/main/telemetry/mavlink.c[1444-1456]

After this PR, docs/Telemetry.md no longer mentions a 19200 SoftSerial limit for iBus, but docs/Serial.md and docs/Blackbox.md still claim SoftSerial is limited to 19200 baud. This is conflicting documentation.

The PR’s stated goal is to fix misleading SoftSerial-limit docs; this should be applied consistently across the documentation set.

• docs/Telemetry.md[231-237]
• docs/Serial.md[46-48]
• docs/Blackbox.md[68-75]

docs/Telemetry.md no longer states SoftSerial is limited to 19200 baud, but docs/Serial.md and docs/Blackbox.md still state (as a hard limit) that SoftSerial is limited to 19200. This creates contradictory documentation after this PR.

The SoftSerial code path takes a baud parameter and configures timers from it without a clear 19200 cap, so documentation that presents 19200 as a strict limit is inconsistent with the current implementation.

• docs/Telemetry.md[205-236]
• docs/Serial.md[36-49]
• docs/Blackbox.md[68-76]
• src/main/drivers/serial_softserial.c[170-189]
• src/main/drivers/serial_softserial.c[204-345]

Update the other docs to match the new reality (e.g., remove the “limited to 19200” hard-limit phrasing) or rephrase consistently as a practical/recommended limit if that’s the intended guidance (e.g., “SoftSerial may be unreliable at high baud rates; prefer hardware UART for >19200 / high bandwidth”).

The updated MAVLink line uses a comma splice (“transmit-only, is usable”), which is grammatically awkward and can be misread.

This is purely a documentation clarity/readability fix.

• docs/Telemetry.md[205-210]

Reword to something like:

• “MAVLink implementation in INAV is transmit-only and usable at low baud rates. MAVLink V1 and V2 are supported.”

docs/Telemetry.md says MAVLink is transmit-only, but the implementation processes inbound MAVLink messages. This is incorrect documentation and can lead users to wrong configuration/expectations.

The telemetry MAVLink code contains an explicit receive loop and dispatches received message IDs.

• docs/Telemetry.md[205-210]
• src/main/telemetry/mavlink.c[1388-1433]
• src/main/telemetry/mavlink.c[1444-1456]

docs/Telemetry.md no longer states SoftSerial is limited to 19200 baud, but docs/Serial.md and docs/Blackbox.md still state (as a hard limit) that SoftSerial is limited to 19200. This creates contradictory documentation after this PR.

The SoftSerial code path takes a baud parameter and configures timers from it without a clear 19200 cap, so documentation that presents 19200 as a strict limit is inconsistent with the current implementation.

• docs/Telemetry.md[205-236]
• docs/Serial.md[36-49]
• docs/Blackbox.md[68-76]
• src/main/drivers/serial_softserial.c[170-189]
• src/main/drivers/serial_softserial.c[204-345]

Update the other docs to match the new reality (e.g., remove the “limited to 19200” hard-limit phrasing) or rephrase consistently as a practical/recommended limit if that’s the intended guidance (e.g., “SoftSerial may be unreliable at high baud rates; prefer hardware UART for >19200 / high bandwidth”).

After this PR, docs/Telemetry.md no longer mentions a 19200 SoftSerial limit for iBus, but docs/Serial.md and docs/Blackbox.md still claim SoftSerial is limited to 19200 baud. This is conflicting documentation.

The PR’s stated goal is to fix misleading SoftSerial-limit docs; this should be applied consistently across the documentation set.

• docs/Telemetry.md[231-237]
• docs/Serial.md[46-48]
• docs/Blackbox.md[68-75]

docs/Telemetry.md no longer states SoftSerial is limited to 19200 baud, but docs/Serial.md and docs/Blackbox.md still state (as a hard limit) that SoftSerial is limited to 19200. This creates contradictory documentation after this PR.

The SoftSerial code path takes a baud parameter and configures timers from it without a clear 19200 cap, so documentation that presents 19200 as a strict limit is inconsistent with the current implementation.

• docs/Telemetry.md[205-236]
• docs/Serial.md[36-49]
• docs/Blackbox.md[68-76]
• src/main/drivers/serial_softserial.c[170-189]
• src/main/drivers/serial_softserial.c[204-345]

Update the other docs to match the new reality (e.g., remove the “limited to 19200” hard-limit phrasing) or rephrase consistently as a practical/recommended limit if that’s the intended guidance (e.g., “SoftSerial may be unreliable at high baud rates; prefer hardware UART for >19200 / high bandwidth”).

The updated MAVLink line uses a comma splice (“transmit-only, is usable”), which is grammatically awkward and can be misread.

This is purely a documentation clarity/readability fix.

• docs/Telemetry.md[205-210]

Reword to something like:

• “MAVLink implementation in INAV is transmit-only and usable at low baud rates. MAVLink V1 and V2 are supported.”

The updated MAVLink line uses a comma splice (“transmit-only, is usable”), which is grammatically awkward and can be misread.

This is purely a documentation clarity/readability fix.

• docs/Telemetry.md[205-210]

Reword to something like:

• “MAVLink implementation in INAV is transmit-only and usable at low baud rates. MAVLink V1 and V2 are supported.”

mavlinkParseRxStats() in GENERIC mode unconditionally assigns rxLinkStatistics.uplinkRSSI = -msg->rssi;. MAVLink defines rssi == UINT8_MAX (255) as invalid/unknown, so the new code turns this into -255, which downstream code interprets as an extremely poor (but valid) dBm.

• MAVLink RADIO_STATUS.rssi is uint8_t with values [0..254], 255 = invalid/unknown.
• The same function already treats msg->rssi != 255 specially for LQ, indicating the sentinel is expected.
• OSD displays rxLinkStatistics.uplinkRSSI directly and compares it to osdConfig()->rssi_dbm_alarm, so -255 can trigger alarms even though RSSI is unknown.

• src/main/telemetry/mavlink.c[1318-1328]

• Only negate when msg->rssi != UINT8_MAX; otherwise set uplinkRSSI to a defined “unknown” representation that won’t be misinterpreted as a real low dBm (e.g. 0, or a dedicated sentinel plus consumer handling).
• Make the cast explicit to avoid any ambiguity: -(int16_t)msg->rssi.

mavlinkParseRxStats() in GENERIC mode unconditionally assigns rxLinkStatistics.uplinkRSSI = -msg->rssi;. MAVLink defines rssi == UINT8_MAX (255) as invalid/unknown, so the new code turns this into -255, which downstream code interprets as an extremely poor (but valid) dBm.

• MAVLink RADIO_STATUS.rssi is uint8_t with values [0..254], 255 = invalid/unknown.
• The same function already treats msg->rssi != 255 specially for LQ, indicating the sentinel is expected.
• OSD displays rxLinkStatistics.uplinkRSSI directly and compares it to osdConfig()->rssi_dbm_alarm, so -255 can trigger alarms even though RSSI is unknown.

• src/main/telemetry/mavlink.c[1318-1328]

• Only negate when msg->rssi != UINT8_MAX; otherwise set uplinkRSSI to a defined “unknown” representation that won’t be misinterpreted as a real low dBm (e.g. 0, or a dedicated sentinel plus consumer handling).
• Make the cast explicit to avoid any ambiguity: -(int16_t)msg->rssi.

mavlinkParseRxStats() in GENERIC mode unconditionally assigns rxLinkStatistics.uplinkRSSI = -msg->rssi;. MAVLink defines rssi == UINT8_MAX (255) as invalid/unknown, so the new code turns this into -255, which downstream code interprets as an extremely poor (but valid) dBm.

• MAVLink RADIO_STATUS.rssi is uint8_t with values [0..254], 255 = invalid/unknown.
• The same function already treats msg->rssi != 255 specially for LQ, indicating the sentinel is expected.
• OSD displays rxLinkStatistics.uplinkRSSI directly and compares it to osdConfig()->rssi_dbm_alarm, so -255 can trigger alarms even though RSSI is unknown.

• src/main/telemetry/mavlink.c[1318-1328]

• Only negate when msg->rssi != UINT8_MAX; otherwise set uplinkRSSI to a defined “unknown” representation that won’t be misinterpreted as a real low dBm (e.g. 0, or a dedicated sentinel plus consumer handling).
• Make the cast explicit to avoid any ambiguity: -(int16_t)msg->rssi.

hrstSent is a function-static counter used to rate-limit the "HRST" indication when BOXHOMERESET is active, but it is never reset when the mode becomes inactive. This permanently disables the HRST indication after the first limited run.

A similar flight-mode text implementation resets hrstSent when BOXHOMERESET is not active, allowing each new activation to show the indication again.

• src/main/telemetry/hott.c[229-382]

• After the flight-mode selection logic, add something like:
• if (!IS_RC_MODE_ACTIVE(BOXHOMERESET) && hrstSent > 0) hrstSent = 0;
• Optionally also reset hrstSent when disarmed to avoid carrying state across arm cycles.

The function returns early on !STATE(GPS_FIX) (or !STATE(GPS_FIX) && !STATE(GPS_ESTIMATED_FIX)), skipping the newly added free_char status updates. Because the message struct is reused across calls (not memset each time), the free_char bytes can retain stale values after GPS fix loss.

initialiseGPSMessage() zeros the struct once at init; hottPrepareGPSResponse() mutates fields in-place and has an early return on no-fix.

• src/main/telemetry/hott.c[180-187]
• src/main/telemetry/hott.c[229-381]

Choose one of:

1. Set a safe default for free_char1..3 (e.g. blanks or "---" / "NOF") before the GPS-fix early return and also set them in the no-fix branch.
2. Move the free_char flight-mode/status computation above the GPS-fix early return so it always runs. Also consider clearing home_direction/flight_direction in the no-fix path to avoid other stale fields.

hrstSent is a function-static counter used to rate-limit the "HRST" indication when BOXHOMERESET is active, but it is never reset when the mode becomes inactive. This permanently disables the HRST indication after the first limited run.

A similar flight-mode text implementation resets hrstSent when BOXHOMERESET is not active, allowing each new activation to show the indication again.

• src/main/telemetry/hott.c[229-382]

• After the flight-mode selection logic, add something like:
• if (!IS_RC_MODE_ACTIVE(BOXHOMERESET) && hrstSent > 0) hrstSent = 0;
• Optionally also reset hrstSent when disarmed to avoid carrying state across arm cycles.

The function returns early on !STATE(GPS_FIX) (or !STATE(GPS_FIX) && !STATE(GPS_ESTIMATED_FIX)), skipping the newly added free_char status updates. Because the message struct is reused across calls (not memset each time), the free_char bytes can retain stale values after GPS fix loss.

initialiseGPSMessage() zeros the struct once at init; hottPrepareGPSResponse() mutates fields in-place and has an early return on no-fix.

• src/main/telemetry/hott.c[180-187]
• src/main/telemetry/hott.c[229-381]

Choose one of:

1. Set a safe default for free_char1..3 (e.g. blanks or "---" / "NOF") before the GPS-fix early return and also set them in the no-fix branch.
2. Move the free_char flight-mode/status computation above the GPS-fix early return so it always runs. Also consider clearing home_direction/flight_direction in the no-fix path to avoid other stale fields.

hrstSent is a function-static counter used to rate-limit the "HRST" indication when BOXHOMERESET is active, but it is never reset when the mode becomes inactive. This permanently disables the HRST indication after the first limited run.

A similar flight-mode text implementation resets hrstSent when BOXHOMERESET is not active, allowing each new activation to show the indication again.

• src/main/telemetry/hott.c[229-382]

• After the flight-mode selection logic, add something like:
• if (!IS_RC_MODE_ACTIVE(BOXHOMERESET) && hrstSent > 0) hrstSent = 0;
• Optionally also reset hrstSent when disarmed to avoid carrying state across arm cycles.

The function returns early on !STATE(GPS_FIX) (or !STATE(GPS_FIX) && !STATE(GPS_ESTIMATED_FIX)), skipping the newly added free_char status updates. Because the message struct is reused across calls (not memset each time), the free_char bytes can retain stale values after GPS fix loss.

initialiseGPSMessage() zeros the struct once at init; hottPrepareGPSResponse() mutates fields in-place and has an early return on no-fix.

• src/main/telemetry/hott.c[180-187]
• src/main/telemetry/hott.c[229-381]

Choose one of:

1. Set a safe default for free_char1..3 (e.g. blanks or "---" / "NOF") before the GPS-fix early return and also set them in the no-fix branch.
2. Move the free_char flight-mode/status computation above the GPS-fix early return so it always runs. Also consider clearing home_direction/flight_direction in the no-fix path to avoid other stale fields.

The retry loop in icm40609dDeviceDetect() runs one extra time due to do { ... } while (attemptsRemaining--); with an unsigned counter. This adds an extra delay on failed detection and obscures intent.

This does not cause an infinite loop, but it does perform 6 attempts when initialized to 5.

• src/main/drivers/accgyro/accgyro_icm40609d.c[174-198]

Replace with an explicit bounded loop, e.g.:

The retry loop in icm40609dDeviceDetect() runs one extra time due to do { ... } while (attemptsRemaining--); with an unsigned counter. This adds an extra delay on failed detection and obscures intent.

This does not cause an infinite loop, but it does perform 6 attempts when initialized to 5.

• src/main/drivers/accgyro/accgyro_icm40609d.c[174-198]

Replace with an explicit bounded loop, e.g.:

MSP2_INAV_WIND currently writes wind speed/angle values unconditionally, and only sets a validity flag afterward. Because the wind estimator can become invalid without clearing the last estimated wind vector, the MSP reply can contain non-zero (stale) values while flags.bit0 == 0, contradicting the documented contract (“0 if unavailable”).

• getEstimatedHorizontalWindSpeed() computes magnitude/angle from cached estimatedWind[] regardless of validity.
• The estimator invalidation path clears hasValidWindEstimate but does not reset estimatedWind[].
• The MSP docs for MSP2_INAV_WIND state the fields are zero when unavailable.

• src/main/fc/fc_msp.c[1603-1618]

• Check isEstimatedWindSpeedValid() first.
• If invalid: write windSpeed=0, windAngle=0, flags=0.
• If valid: compute and write speed/angle, set flags=1.
• Optionally clamp the float speed to [0, UINT16_MAX] before casting to avoid wrap/truncation surprises.

getActiveSpeed() assigns navWaypoint_t.p1/p2 (signed int16_t) to a uint16_t temporary and returns it for AIRPLANE without validating it. Negative values (e.g. -1) become large unsigned values (e.g. 65535) and later get clamped to maxSpeed, producing an unintended full-speed demand.

Waypoint params are stored in navWaypoint_t as signed integers. The fixed-wing WP Auto Speed path uses getActiveSpeed() to derive speed demand and constrains it between fw_auto_speed_min_speed and fw_auto_speed_max_speed.

• src/main/navigation/navigation.c[4321-4353]
• src/main/navigation/navigation.h[553-560]
• src/main/navigation/navigation_fixedwing.c[939-948]

• Keep waypoint speed as a signed type (int16_t) when reading p1/p2.
• Treat <= 0 as “no WP speed set” (return 0 or fall back to configured default).
• Optionally clamp to sane bounds before returning (e.g., MIN(wpSpeed, navConfig()->general.max_auto_speed) for MR; for FW, either clamp or rely on the later constrain but only after ensuring non-negative).

autoSpeedIsActive is defined at file scope without static, giving it external linkage even though it is only referenced inside navigation_fixedwing.c.

There is already a public accessor isFixedwingAutoSpeedActive(), so the backing flag does not need external linkage.

• src/main/navigation/navigation_fixedwing.c[74-78]

Change the definition to static bool autoSpeedIsActive = false; (or move it into a private module struct) to keep the symbol local to the translation unit.

The target defines PWM-beeper parameters (BEEPER_PWM_FREQUENCY and a TIM_USE_BEEPER timer mapping), but targetConfiguration() does not enable beeperConfig()->pwmMode. As a result, beeperPwmInit() is not called and the timer-based beeper output is never configured.

sound_beeper.c only initializes PWM beeper when beeperConfig()->pwmMode is true; otherwise it uses GPIO toggling.

• src/main/target/HUMMINGBIRD_FC305_H7/config.c[18-29]

1. Include fc/config.h in config.c.
2. Set beeperConfigMutable()->pwmMode = true; in targetConfiguration() (if the hardware is passive / intended to use PWM).
3. If the hardware is actually an active buzzer, remove the PWM-specific configuration (timer mapping / frequency) to avoid confusion.

TARGET_BOARD_IDENTIFIER is duplicated between two different targets (HUMMINGBIRD_FC305 and HUMMINGBIRD_FC305_H7). Since MSP exports this identifier, tools/users relying on boardIdentifier cannot reliably distinguish which firmware/target is running.

The new target defines TARGET_BOARD_IDENTIFIER "HBRD", but the existing HUMMINGBIRD_FC305 target already uses the same identifier.

• src/main/target/HUMMINGBIRD_FC305_H7/target.h[20-22]

Change TARGET_BOARD_IDENTIFIER for HUMMINGBIRD_FC305_H7 to a unique (ideally 4-character, uppercase) identifier, and ensure any documentation/release tooling that references the identifier is updated accordingly.

A rebooting peripheral can be mistaken for a conflicting live node because its previous NodeStatus entry remains cached for 10 seconds. This causes its persisted node ID to be replaced during rapid restart.

The live-node table contains only node IDs and retains them until the stale timeout, so presence in that table does not prove another node is still broadcasting. Preserve the stored mapping unless the occupant is verified as a different currently-live node, or defer allocation until the cached entry expires.

• src/main/drivers/dronecan/dronecan_dna_server.c[177-192]
• src/main/drivers/dronecan/dronecan_node_status.c[150-161]
• src/main/drivers/dronecan/dronecan.h[58-58]

dronecanAsyncCheckTimeout() is executed before processing queued RX frames in dronecanUpdate(). If a response arrives just before the timeout boundary but the next dronecanUpdate() tick occurs at/after the boundary, the slot can be marked ERROR and the queued response will then be ignored by dronecanAsyncHandleServiceResponse() (it only processes when state==PENDING).

The timeout logic uses millis() granularity, so boundary effects are realistic. A correct implementation should always give queued RX frames a chance to resolve the slot before expiring it.

• src/main/drivers/dronecan/dronecan.c[145-168]
• src/main/drivers/dronecan/dronecan_async.c[159-168]

Reorder the NORMAL-state loop so it drains RX (and any resulting TX) first, then calls dronecanAsyncCheckTimeout() after RX handling. Optionally, call the timeout check once per loop iteration after RX+TX drain, so a response in the FIFO always wins over expiring the slot.

getGyroAafConfig() uses int8_t selectedFreq to hold LUT frequencies. For the 42688/42686 path the LUT includes values >127 (e.g. 258, 303), which overflow int8_t and can cause the function to pick the wrong AAF candidate.

This function selects the closest supported AAF cutoff frequency by comparing ABS(desiredFreq - aafConfigs[i].freq) against ABS(desiredFreq - selectedFreq). If selectedFreq wraps, the comparison becomes invalid.

• Change selectedFreq to a wide signed type (e.g. int32_t or uint16_t, but prefer int32_t for safe signed subtraction).
• Ensure the subtraction is performed in a sufficiently wide signed type, e.g.:
  • const int32_t desired = desiredFreq;
  • compare ABS(desired - (int32_t)aafConfigs[i].freq)

• src/main/drivers/accgyro/accgyro_icm42605.c[415-443]

docs/Autotune - fixedwing.md currently states that fw_autotune_rate_adjustment=LIMIT "only ever lowers" the rates. In the code, rate adjustment can step up or down by 10 dps based on measured capability; in LIMIT mode it is merely capped at the starting rate (and can rise back toward that cap).

This is documentation-only, but it can still mislead users who choose LIMIT expecting a strictly one-way decrease.

• docs/Autotune - fixedwing.md[27-27]

Suggested wording example:

• Replace "LIMIT only ever lowers them" with something like "LIMIT will not increase rates above the starting values (but may raise a previously-lowered rate back up to that cap)."

The runtime OUTPUT_MODE_BEEPER path unconditionally commits to PWM mode (beeperConfigMutable()->pwmMode = true) and returns after calling beeperPwmInit(), but beeperPwmInit() can fail and leave the beeper backend uninitialized. In that case pwmWriteBeeper() no-ops and there is no fallback.

• beeperPwmInit() can return early when timerGetTCH() fails.
• pwmWriteBeeper() returns immediately when beeperPwm == NULL.

• src/main/drivers/sound_beeper.c[81-91]

• Make beeperPwmInit() report success (e.g., return bool), or add a small getter like bool beeperPwmIsInitialized(void).
• In the runtime assignment path:
  • only set pwmMode=true and return if initialization succeeded;
  • otherwise continue into the existing compile-time beeper initialization path (or log an error and keep beeper in GPIO mode if possible).

crsfRpm() currently forwards RPM for any ESC slot with dataAge < ESC_DATA_INVALID (255). That suppresses never-initialized slots, but still forwards very stale last-seen values until dataAge saturates at 255, which can take a long time with round-robin polling.

Other telemetry/UI paths treat ESC telemetry as valid only when dataAge <= ESC_DATA_MAX_AGE.

• src/main/telemetry/crsf.c[335-358]

Gate RPM with escState->dataAge <= ESC_DATA_MAX_AGE (or an equivalent freshness threshold) instead of < ESC_DATA_INVALID.

The new SPI AF lookup table headers use CONCAT4(...) but do not include the header that defines it (common/utils.h). They currently compile only due to transitive includes (via drivers/io.h → io_def.h → common/utils.h) and therefore are fragile to include-order changes or reuse.

This is a latent build fragility / maintainability issue: it may not break today, but it can break later during refactors or if another file includes these headers without including common/utils.h first.

• src/main/drivers/bus_spi_stm32h7xx.h[32-38]
• src/main/drivers/bus_spi_stm32f7xx.h[36-42]

gh release create is invoked without explicitly targeting the triggering PR commit (github.event.workflow_run.head_sha), despite comments indicating the tag should be recreated to point at the new commit.

This workflow is publishing firmware for a specific PR commit; the tag should deterministically reference that commit SHA.

• .github/workflows/pr-test-builds.yml[65-97]

The workflow uses the Issues API to manage PR comments but does not grant issues: write in the job permissions.

actions/github-script uses GITHUB_TOKEN, whose scopes are governed by the workflow permissions: block.

• .github/workflows/pr-test-builds.yml[25-28]

The workflow parses PR_NUMBER from an environment variable using parseInt(...) and then uses it without checking for NaN (and without specifying radix 10). If the env var is missing or malformed, this can produce non-deterministic behavior (e.g., NaN in URLs / API params) instead of a clear, deterministic failure.

This job runs with elevated permissions (pull-requests: write) and should validate external inputs (including env vars derived from artifacts/outputs) before use.

• .github/workflows/pr-test-builds.yml[107-110] բավ

Concurrency grouping uses only head_branch, which can collide across forks and cause unrelated runs to cancel each other.

This job publishes per-PR releases; cancellations should be limited to the same PR, not other forks with similarly named branches.

• .github/workflows/pr-test-builds.yml[20-24]

The PR commits DSDL-generated DroneCAN sources/headers under dsdlc_generated, which are generated artifacts.

Generated artifacts should be produced as part of the build (or via an explicit opt-in update command) and not be committed as normal source to keep the repository clean and reproducible.

• src/main/drivers/dronecan/dsdlc_generated/src/uavcan.equipment.air_data.Sideslip.c[1-8]
• cmake/main.cmake[2-12]

CAN timing computation failure is ignored, potentially configuring hardware with invalid values.

The timing helper explicitly returns false for invalid/unsatisfied configurations; initialization should not proceed on failure.

• src/main/drivers/dronecan/libcanard/canard_stm32h7xx_driver.c[162-168]

DroneCAN initialization ignores CAN peripheral init failures.

Proceeding after failed CAN init can cause confusing runtime behavior and make debugging difficult.

• src/main/drivers/dronecan/dronecan.c[404-440]

src/main/drivers/dronecan/dronecan.h is not self-contained: it uses PG_DECLARE but does not include the header that defines it (config/parameter_group.h). This creates brittle include-order dependencies and can break compilation in files that include dronecan.h early (e.g. fc_tasks.c).

PG_DECLARE is defined in src/main/config/parameter_group.h. Some compilation units include dronecan.h before any header that brings in parameter_group.h.

• src/main/drivers/dronecan/dronecan.h[1-19]
• src/main/fc/fc_tasks.c[18-43]
• src/main/config/parameter_group.h[104-110]

PG_DRONECAN_CONFIG is outside the [PG_ID_FIRST..PG_ID_LAST] range because PG_INAV_END wasn’t updated. This prevents MSP parameter-group enumeration from reporting DroneCAN config.

MSP uses PG_ID_FIRST/PG_ID_LAST to enumerate parameter groups.

• src/main/config/parameter_group_ids.h[132-150]
• src/main/fc/fc_msp.c[3899-3919]

processCanardTxQueue() drops frames by popping the TX queue even when the hardware transmit reports “not sent yet” (return 0).

On STM32H7 the transmit function returns 0 when HAL_FDCAN_AddMessageToTxFifoQ fails (e.g. TX FIFO full), which should be retried.

• src/main/drivers/dronecan/dronecan.c[358-375]
• src/main/drivers/dronecan/libcanard/canard_stm32h7xx_driver.c[83-128]

STM32F7 canardSTM32Transmit() reports success even on HAL transmit failure, hiding errors and causing silent packet loss.

Callers use the return value to decide whether to keep or drop frames.

• src/main/drivers/dronecan/libcanard/canard_stm32f7xx_driver.c[127-170]
• src/main/drivers/dronecan/dronecan.c[358-375]

The RX loop decrements its loop counter twice, causing it to skip frames.

canardSTM32GetRxFifoFillLevel() is used to determine how many frames to process.

• src/main/drivers/dronecan/dronecan.c[462-477]

STM32F7 unique ID generation is not unique, causing collisions between devices.

DroneCAN node identification expects a stable per-device unique ID.

• src/main/drivers/dronecan/libcanard/canard_stm32f7xx_driver.c[430-441]
• src/main/drivers/dronecan/libcanard/canard_stm32h7xx_driver.c[388-395]

Decode failures are silently ignored, making it difficult to detect malformed frames or schema mismatches.

This is a new external-input path (CAN bus) where malformed payloads are expected; diagnostics should be available without flooding logs.

• src/main/drivers/dronecan/dronecan.c[47-129]

Logs include raw GNSS coordinates and unstructured strings.

Location data can be sensitive; logs should avoid detailed location output by default and be machine-parseable where possible.

• src/main/drivers/dronecan/dronecan.c[99-135]

Large stack buffers are allocated in DroneCAN handler/sender paths, increasing stack pressure.

Embedded systems often have small stacks per task/ISR; using static/shared buffers or preallocated pools is safer.

• src/main/drivers/dronecan/dronecan.c[158-205]
• src/main/drivers/dronecan/dsdlc_generated/include/uavcan.protocol.GetNodeInfo_res.h[10-16]

The 1Hz scheduler gate runs too frequently right after boot because next_1hz_service_at starts at zero and is advanced via +=.

This causes NodeStatus transmission and stale-transfer cleanup to run far more often than intended immediately after startup.

• src/main/drivers/dronecan/dronecan.c[445-483]