MAG: add LIS2MDL support

[bkleiner]

Configurator PR iNavFlight/inav-configurator#2661

[github-actions]

Test firmware build ready — commit 2699aa1

Download firmware for PR #11655

249 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.

[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

Add LIS2MDL magnetometer support (driver, detection, and CLI enums/docs)

✨ Enhancement 📝 Documentation ⚙️ Configuration changes 🕐 40+ Minutes

AI Description

• Add LIS2MDL compass driver with I2C detection, init, and axis mapping.
• Expose LIS2MDL in mag_hardware CLI setting and target hardware registration.
• Refresh MSP enum references/docs to include new/updated firmware enumerations.

Diagram

graph TD
  A["CLI: settings.yaml"] --> B["compassDetect()"] --> C["lis2mdlDetect()"] --> D["busDeviceInit()"] --> E["I2C bus"]
  F["Target: common_hardware.c"] --> D
  G["MSP enums/docs"] --> A

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Factor a shared ST-mag base (LIS2MDL/LIS3MDL family)

• ➕ Reduces duplicated bus/detect boilerplate across ST magnetometers
• ➕ Centralizes axis mapping conventions and retry/poll patterns
• ➖ Refactor risk across existing, working drivers
• ➖ May complicate simple per-sensor bring-up and debugging

2. Rely on generic I2C address scan + WHO_AM_I table in compassDetect()

• ➕ Less per-driver detection code; easier to add future sensors
• ➕ Single place to tune detection retries/timeouts
• ➖ Harder to preserve current per-sensor behavior and ordering
• ➖ Risk of false positives when multiple devices share addresses

3. Automate MSP enum/doc updates via a single generation step in CI

• ➕ Prevents drift between firmware headers, inav_enums.json, and ref markdown
• ➕ Avoids accidental version regressions and missing newline issues
• ➖ Requires build/CI plumbing and contributor workflow changes
• ➖ Does not directly affect runtime feature functionality

Recommendation: The PR’s approach (dedicated LIS2MDL driver + explicit detect case + stable devHardwareType append) is appropriate for minimizing behavioral risk. The main follow-up worth considering is process-oriented: ensure the MSP enum/doc artifacts are generated from the same firmware source/version consistently (the fc_version change and broad enum churn suggest a regen), and fix the missing newline in inav_enums.json to avoid tooling diffs.

Files changed (12) +350 / -81

Enhancement (6) +181 / -0

bus.hAdd DEVHW_LIS2MDL hardware type ID +1/-0

Add DEVHW_LIS2MDL hardware type ID

• Appends DEVHW_LIS2MDL to devHardwareType_e to provide a stable bus device identifier for the new compass driver.

src/main/drivers/bus.h

compass_lis2mdl.cNew LIS2MDL magnetometer driver (init/read/detect) +135/-0

New LIS2MDL magnetometer driver (init/read/detect)

• Introduces a new I2C-based LIS2MDL driver gated by USE_MAG_LIS2MDL, including WHO_AM_I probing with retries, register configuration for continuous 100Hz operation, and data reads. Applies axis sign adjustment to match the common sensor frame (noting Betaflight compatibility).

src/main/drivers/compass/compass_lis2mdl.c

compass_lis2mdl.hExpose lis2mdlDetect() API +23/-0

Expose lis2mdlDetect() API

• Adds the header declaring lis2mdlDetect(magDev_t*) for integration into the compass detection dispatcher.

src/main/drivers/compass/compass_lis2mdl.h

compass.cWire LIS2MDL into compass autodetect/selection +14/-0

Wire LIS2MDL into compass autodetect/selection

• Includes the new LIS2MDL driver header and adds a MAG_LIS2MDL case in compassDetect(), supporting both explicit selection and fallthrough behavior during MAG_AUTODETECT.

src/main/sensors/compass.c

compass.hAdd MAG_LIS2MDL to magSensor_e +1/-0

Add MAG_LIS2MDL to magSensor_e

• Extends the magnetometer sensor enum with MAG_LIS2MDL so it can be selected via CLI/MSP and used by compassDetect().

src/main/sensors/compass.h

common_hardware.cRegister LIS2MDL as an I2C bus device for autodetect +7/-0

Register LIS2MDL as an I2C bus device for autodetect

• Registers DEVHW_LIS2MDL on I2C (default address 0x1E) and provides a default bus macro fallback to MAG_I2C_BUS when LIS2MDL_I2C_BUS is not defined.

src/main/target/common_hardware.c

Documentation (2) +88 / -38

Settings.mdDocument LIS2MDL as a selectable magnetometer +1/-0

Document LIS2MDL as a selectable magnetometer

• Adds LIS2MDL to the documented list of mag hardware options in CLI settings documentation.

docs/Settings.md

inav_enums_ref.mdRegenerate MSP enum reference markdown +87/-38

Regenerate MSP enum reference markdown

• Updates the rendered enum reference to match the updated enum set, including new DroneCAN enums and the MAG_LIS2MDL entry. Removes led_pin_pwm_mode_e section and updates various enum tables to reflect renames/additions.

docs/development/msp/inav_enums_ref.md

Other (4) +81 / -43

inav_enums.jsonRefresh MSP enum JSON (add MAG_LIS2MDL and other enum updates) +77/-42

Refresh MSP enum JSON (add MAG_LIS2MDL and other enum updates)

• Updates the MSP enum export, including adding MAG_LIS2MDL and DEVHW_LIS2MDL, plus multiple other enum additions/renames (e.g., BARO_CRSF, GPS_CRSF/DRONECAN, DroneCAN-related enums). Also changes the recorded fc_version and removes the trailing newline.

docs/development/msp/inav_enums.json

CMakeLists.txtBuild: include LIS2MDL compass driver sources +2/-0

Build: include LIS2MDL compass driver sources

• Adds compass_lis2mdl.c/.h to the common firmware source list so the new driver can be compiled when enabled.

src/main/CMakeLists.txt

settings.yamlExpose LIS2MDL in mag_hardware CLI enum values +1/-1

Expose LIS2MDL in mag_hardware CLI enum values

• Adds LIS2MDL to the mag_hardware values list, aligning CLI/MSP configuration options with the new driver and magSensor_e enum.

src/main/fc/settings.yaml

common_post.hEnable USE_MAG_LIS2MDL in common target feature set +1/-0

Enable USE_MAG_LIS2MDL in common target feature set

• Defines USE_MAG_LIS2MDL alongside other common magnetometer enables so the driver can be built/used on common targets.

src/main/target/common_post.h

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

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. Mag enum IDs shifted 🐞 Bug ≡ Correctness

Description

MAG_LIS2MDL was inserted before MAG_FAKE in magSensor_e, shifting existing numeric IDs used
for persisted compassConfig()->mag_hardware and MSP reporting. Because the compass PG version
wasn’t bumped, older stored values will be restored and can now map to the wrong sensor type after
upgrade.

Code

src/main/sensors/compass.h[R47-49]

+    MAG_LIS2MDL,
    MAG_FAKE,
    MAG_MAX = MAG_FAKE

Evidence

The enum insertion changes the numeric value of MAG_FAKE, while the value is persisted/restored
unchanged (PG version matches) and transmitted over MSP as a raw uint8_t, so upgrades can
reinterpret existing configs with a different sensor type.

src/main/sensors/compass.h[29-50]
src/main/fc/settings.yaml[10-12]
src/main/sensors/compass.c[69-75]
src/main/config/parameter_group.c[86-94]
src/main/fc/fc_msp.c[1470-1481]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`magSensor_e` numeric values are persisted (EEPROM parameter groups) and sent over MSP as a `uint8_t`. Inserting `MAG_LIS2MDL` before an existing enumerator shifts the numeric value of `MAG_FAKE` (and any later items), which can cause incorrect sensor selection after firmware upgrade.

### Issue Context
- `compassConfig()->mag_hardware` is stored/restored via the parameter group system.
- Parameter groups only restore when the stored version matches (`pgLoad`), and compass PG version remains unchanged.

### Fix Focus Areas
- Ensure existing `magSensor_e` numeric IDs remain unchanged (e.g., append `MAG_LIS2MDL` after existing values, or assign explicit numeric values to keep prior IDs stable).
- Update `MAG_MAX` accordingly.
- Sync `settings.yaml` (and generated MSP enum docs) to the corrected numeric ordering.

### Fix Focus Areas (code references)
- src/main/sensors/compass.h[29-50]
- src/main/fc/settings.yaml[10-12]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. MPU9250 falls into LIS2MDL 🐞 Bug ≡ Correctness

Description

MAG_MPU9250 ends with an unconditional FALLTHROUGH, and the newly-added MAG_LIS2MDL case
attempts detection before honoring the “specific sensor requested” break pattern. This means an
explicitly-selected MPU9250 that fails detection can now incorrectly probe/select LIS2MDL instead of
failing.

Code

src/main/sensors/compass.c[R212-216]

+    case MAG_LIS2MDL:
+#ifdef USE_MAG_LIS2MDL
+        if (lis2mdlDetect(dev)) {
+            magHardware = MAG_LIS2MDL;
+            break;

Evidence

The new LIS2MDL case is placed immediately after a case that always falls through, and LIS2MDL’s
detection attempt happens before checking whether the caller requested a specific sensor
(non-autodetect).

src/main/sensors/compass.c[203-224]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The `MAG_MPU9250` switch case falls through unconditionally to the next case. With the new `MAG_LIS2MDL` case inserted next, an explicit MPU9250 selection that fails can now attempt LIS2MDL detection and potentially select it, which is inconsistent with the explicit-selection behavior of other sensors.

### Issue Context
Other magnetometer cases implement:
- attempt detect
- if not autodetect, `break;`
- else `FALLTHROUGH;`

### Fix Focus Areas
- Add the same `if (magHardwareToUse != MAG_AUTODETECT) break;` guard to the `MAG_MPU9250` case before `FALLTHROUGH;`.
- Alternatively, prevent `MAG_LIS2MDL` from attempting detection when reached via fallthrough from a non-autodetect selection.

### Fix Focus Areas (code references)
- src/main/sensors/compass.c[203-224]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can route each action level your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[sensei-hacker]

Thanks for this. FYI when you re-write history and force push it screws up my process and takes a lot longer for me.

I have notes about what has been reviewed as good, what might need to be changed, etc. But then when history is deleted and a new history written, all the work I've done so far goes out the window and I have to start over again every time.

Not to mention when I write and run tests, then find out I've been testing commits that no longer exist. I then have to force my own copy and start over.

[sensei-hacker]

Thanks for this. Can you handle the merge conflict? I don't have permission on your branch to do so.

[bkleiner]

Thanks for this. Can you handle the merge conflict? I don't have permission on your branch to do so.

Done. is src/utils/update_cli_docs.py still the canonical way to re-gen these files? seems like it hasn't been run in a while

[github-actions]

RAM / Flash usage vs. base commit 8cccf49 — commit 2699aa1

Using the nearest available size baseline — the PR's exact base commit has no stored baseline yet.

Target	Flash Δ	RAM Δ
MATEKF405 ⚠️	+372 B (+0.05%)	+40 B (+0.03%)
MATEKF722	+244 B (+0.05%)	+32 B (+0.03%)
MATEKF765 ⚠️	+300 B (+0.04%)	+24 B (+0.01%)
MATEKH743 ⚠️	+364 B (+0.05%)	+32 B (+0.02%)

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

[sensei-hacker]

Awesome, thanks. Merging.

is src/utils/update_cli_docs.py still the canonical way to re-gen these files? seems like it hasn't been run in a while

That's an excellent point / question. Maybe we should have a CI check for that similar to the check for Settings.md ?

[bkleiner]

Awesome, thanks. Merging.

is src/utils/update_cli_docs.py still the canonical way to re-gen these files? seems like it hasn't been run in a while

That's an excellent point / question. Maybe we should have a CI check for that similar to the check for Settings.md ?

Threw something together #11875