Hardware: Thingy:91 X (PCA20065), nRF9151
Firmware: nRF Connect SDK v3.3.0, TF-M non-secure build, mfw_nrf91x1_2.0.2 and mfw_nrf91x1_2.0.4
Config: CONFIG_LTE_NETWORK_MODE_LTE_M_GPS, MODEM_ANTENNA lib enabled with the Thingy:91 X defaults (%XCOEX0=1,1,1565,1586, %XMIPIRFFEDEV, %XMIPIRFFECTRL init/on/off/pwroff)
Network: LTE-M (AcT 7), US carrier, CEREG registers status 5
GNSS API: nrf_modem_gnss, event handler installed after nrf_modem_lib_init, 1 Hz PVT events arrive in all cases below
Problem:
Once AT+CFUN=1 has run, GNSS stops acquiring satellites. PVT frames keep coming at 1 Hz with zero tracked satellites, outdoors under open sky, for as long as we let it run (up to 420 s). This holds in LTE-M+GPS coexistence and also in GNSS-only mode entered afterward with AT+CFUN=31. The only recovery is a stop at AT+CFUN=0 followed by starting GNSS from AT+CFUN=31.
Reproduction:
Fails: reboot -> AT+CFUN=1 -> wait for +CEREG: 0,5 -> AT+CFUN=31 -> nrf_modem_gnss_start -> no satellites in 150 s.
Works: reboot -> AT+CFUN=31 -> nrf_modem_gnss_start -> fix in less than 25 seconds.
Full test matrix (open sky, 4+ satellites available):
boot -> CFUN=31 fix 22.6 s
boot -> CFUN=1 -> reg -> CFUN=31 no fix
boot -> CFUN=1 -> reg -> %XCOEX0 (returns OK) -> CFUN=31 no fix
boot -> CFUN=1 -> reg -> CFUN=0 -> CFUN=31 fix 35.0 s
boot -> CFUN=0 -> CFUN=1 -> reg -> GNSS start no fix
boot -> CFUN=1 -> A-GNSS inject -> CFUN=0 -> CFUN=1-> GNSS start no fix
fix, then seconds later GNSS start under CFUN=1 fix 2.3 s
Additional observations:
- %XCOEX0 written while CFUN=1 returns OK but has no observable effect, but written at CFUN=0 it behaves normally.
- Hot re-acquisition under LTE works, as indicated above. So the failure looks specific to cold/warm search, not to GNSS radio time-sharing as such. But I could be wrong
- One occurrence on 2.0.2: after repeated cycles of these tests the SiP stopped responding entirely (no UART, no AT) and only full power removal recovered it. The mfw_nrf91x1_2.0.3 release notes mention "In some cases with non-optimal application behavior, the modem could enter an unrecoverable state" under GNSS and LTE interoperability. So, we upgraded to 2.0.4 for that reason, but the failure above is unchanged.
Questions:
1. Is GNSS cold acquisition expected to work when GNSS is activated with AT+CFUN=31 after LTE has been active, without passing through AT+CFUN=0?
2. Is there a known issue matching this on mfw_nrf91x1 2.0.x?
3. What do you need to progress this? We can provide a modem trace of the failing and working sequences on request.