GPS: switching from driver-based provider to UBLOX at runtime causes hard fault (FC non-responsive)

[daijoubu]

Bug Report

INAV version: release/9.1 (also present in master)

Description

When gps_provider is configured as a driver-based provider (MSP or FAKE) and then changed to UBLOX via the CLI , the flight controller becomes non-responsive (hard fault) and requires a power cycle to recover. Setting change was not saved.

Steps to Reproduce

1. Configure gps_provider = MSP (or FAKE) and save
2. Reboot so the FC initialises with the driver-based provider
3. Connect via CLI
4. Type set gps_provider = UBLOX (do not type save)
5. FC becomes non-responsive immediately

Root Cause

gpsState.gpsConfig is a pointer to the live parameter group data. When a CLI set command changes gps_provider, the value at gpsState.gpsConfig->provider updates immediately — before any reboot.

Driver-based providers (MSP, FAKE) take the isDriverBased = true shortcut in gpsInit() (gps.c:470) and return without ever opening a serial port. gpsState.gpsPort remains NULL.

On the next scheduler tick, gpsUpdate() dispatches to gpsHandleUBLOX() via the updated provider value. gpsHandleUBLOX() immediately calls serialRxBytesWaiting(gpsState.gpsPort) with a NULL pointer → hard fault.

The reverse direction (UBLOX → driver-based) does not crash because driver-based handlers do not access gpsState.gpsPort.

Expected Behaviour

The FC should not crash. Ideally the provider change is handled gracefully (close any existing serial port, reinitialise for the new provider). At minimum it should not hard fault.

Affected Providers

Any transition from a driver-based GPS provider to UBLOX at runtime:

• MSP → UBLOX
• FAKE → UBLOX

Environment

• Branch: release/9.1 (and master)
• Trigger: CLI set gps_provider = UBLOX while running a driver-based provider, without save/reboot