nRF9151 (Thingy:91 X): GNSS never acquires satellites after AT+CFUN=1

[SidTactacam]

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.

[SidTactacam]

Hey Syed,

Thank you for getting back to me and for your patience here.

Ack on the note on the %XCOEX0 only taking effect from CFUN=0. that matches what we observed.

Since the original post we have re-verified the modem firmware version with mfw_nrf91x1_2.0.4 and reproduced the issue many more times on 2.0.4. Traces for both cases are present in the g-drive link below, captured back to back at the same location.

drive.google.com/.../view(or let me know if there is a secure place I can upload the traces)

1. mfw204_failing_cfun1_then_cfun31.bin
Cold boot -> AT+CFUN=1 -> wait for +CEREG: 0,5 -> AT+CFUN=31 -> nrf_modem_gnss_start.
GNSS ran 120 s, PVT events at 1 Hz, zero satellites tracked, no fix.

2. mfw204_working_cfun0_then_cfun31.bin
Same as above, except AT+CFUN=0 was issued before AT+CFUN=31.
Fix in 58,230 ms.

The only difference between the two sequences is the pass through CFUN=0. The CFUN=0 case acquires and fixes while the direct CFUN=1 -> CFUN=31 case tracks nothing.

Happy to capture anything further if that helps.

Thanks,
Sid.