[NRF9151] Modem does not connect after SIM deactivate/reactivate

Hi,

I’m using the Thingy:91X board with the nRF9151 chip, modem firmware version 2.0.2, and SDK version 2.9.0.

We’re encountering a serious issue: the modem does not reconnect after the SIM has been deactivated and then reactivated.

I’ve tried:

  • sys_reboot(SYS_REBOOT_COLD)

  • Placing the modem offline (lte_lc_offline())

  • Shutting down the modem library (nrf_modem_lib_shutdown())

  • Forcing a hard reboot via the watchdog

None of these approaches has worked.

Do you have any suggestions for resolving this issue?

The only workaround so far (which isn’t acceptable) is to manually power the device off and on.

Regards,
Mathieu

Parents
  • Not sure, how you really tested that.

    There may be two pitfalls:

    - the reactivation of the SIM may take some time (in some cases more minutes, even longer, especially, if you deactivate and reactivate multiple times in just a few minutes)

    - some rejection cause are treated "sticky" by the modem. That requires usually to wait some time or do a "lte_lc_power_off/lte_lc_normal" cycle (but I didn't retest that for a nRF9151)

    So, let me propose, that you try to wait a minute or so after reactivate the SIM until you test to connect the modem again. If that results in rejected registrations, then try a "lte_lc_power_off/lte_lc_normal" cycle.

  • Hello Achim,

    I let the card run for a few days, but it never reconnected to the network. However, I have a watchdog that reboots the card after “x” minutes without data. Should I disable it? Could it be causing a conflict with the modem in the new version?

    I already tried the lte_lc_power_off/lte_lc_normal cycle, but it didn’t work (the watchdog still rebooted the card after a few minutes).

    Best regards,
    Mathieu

  • Sounds strange, but though I haven't (re-)tested that, I'm not sure, if the things have changed in nRF9151/mfw 2.0.2 . That stuff with the "sticky network rejection" is some of the "deep spec documented" features, which is hard to understand and close to impossible to test.

    I will check the SIM deactivation/activation using 1nce and a nRF9151-DK. Let's see, what I get.  

  • (the watchdog still rebooted the card after a few minutes)

    That depends on how many "a few" are in numbers ;-).

    Depending on the used bands and modes (LTE-M/NB-IoT) such a network search may take some more time. I usually start with 3 min and double that search time for each search after a quiet phase.

  • The watchdog reboots the card after 5 minutes.

    On reboot, the app restarts by calling (after initializing other components) nrf_modem_lib_init, modem_info_rsrp_register, and lte_lc_connect_async.

Reply Children
  • If 5 minutes are OK depends on the bands, the modes and the available networks. If you want to ensure, that this isn't the cause, just use 15 minutes and see, if that changes.  

  • If I understand correctly, the calls to lte_lc_power_off and lte_lc_normal should work.

    I’ll retry them and increase the watchdog timeout to give the modem enough time to reconnect without being reset during the process.

    I’ll let you know the results.

  • If I understand correctly, the calls to lte_lc_power_off and lte_lc_normal should work.

    Yes, that was my experience with the nRF9160/mfw1.3.7 and is now the same in the retest with the nRF9151/mfw2.0.2. 

    I’ll retry them and increase the watchdog timeout to give the modem enough time to reconnect without being reset during the process.

    It should be at least worth to be tested.

    I’ll let you know the results.

    I'm looking forward.

  • I tried retesting using the lte_lc_power_off / lte_lc_normal cycle on disconnection, but now my device doesn’t connect at all, it just hangs after the “Searching” event (the same thing happens when I deactivate/reactivate the SIM but this SIM was always activated).

    I enabled tracing as described here: https://docs.nordicsemi.com/bundle/ncs-2.9.0/page/nrf/libraries/modem/nrf_modem_lib/nrf_modem_lib_trace.html, but all I get are these logs:

    [00:00:01.526,733] <inf> modem_trace_backend: Modem_trace RTT backend channel 1  
    [00:00:01.526,733] <inf> nrf_modem_lib_trace: Trace thread ready  
    [00:00:01.534,637] <inf> nrf_modem_lib_trace: Trace level override: 2  
    [00:00:01.782,501] <err> nrf_modem_lib_trace: trace_backend.write failed with err: -63  
    …  
    [00:00:08.544,372] <err> nrf_modem_lib_trace: trace_backend.write failed with err: -63  
    [00:00:13.396,179] <inf> lte_monitor: Network: Searching
    I haven’t changed anything in this software version, and it was working fine two weeks ago. I’m really lost.
  • I haven’t changed anything in this software version, and it was working fine two weeks ago. I’m really lost.

    You added the power_off/normal cycle and the modem trace via RTT.

    I would start removing both and retest. If you use versioning, that may be easier to checkout a last working version and retest that.

    And then adding one change step by step and see, if both stops the device from working or just one.

    ----------------------------------------------------------------------------------------

    I'm used to trace the mode via UART and sometimes use the FLASH to keep a the trace for a time span (and afterward write that to the UART).

    I never tried the RTT interface for the modem trace before, but at least using a nRF9151-DK, NCS 2.9.2, Ubuntu doesn't work for me either. I enabled it via the snippet, it start to report quite a lot of "trace_backend.write failed with err: -63". But using

    nrfjprog --reset && JLinkRTTLogger -Device NRF9151_XXCA -If SWD -Speed 50000  modemtracesrtt.bin

    (see How to capture nrf9160 modem traces using RTT? ) 

    only reports:

    SEGGER J-Link RTT Logger
    Compiled Mar  5 2025 14:51:21
    (c) 2016-2017 SEGGER Microcontroller GmbH, www.segger.com
             Solutions for real time microcontroller applications

    Default logfile path: /home/achim/.config/SEGGER

    ------------------------------------------------------------ 


    ------------------------------------------------------------ 
    Connected to:
      SEGGER J-Link (unknown)
      S/N: 1051240195

    Searching for RTT Control Block...OK.
    3 up-channels found:
    0: Terminal
    1: 
    2: 
    Selected RTT Channel description: 
      Index: 1
      Name:  
      Size:  0 bytes.

    Output file: modemtracesrtt.bin

    Getting RTT data from target. Press any key to quit.
    ------------------------------------------------------------ 

    Transfer rate: 0 Bytes/s Data written: 0 Bytes 0

    Not sure, may be this requires someone from Nordic to retest the modem trace via RTT. 

Related