GM02SP lost cellular RF after LR8.2.1.0 → LR8.2.2.1 upgrade — possible RF calibration/configuration issue

LTE-M / NB-IoT (Monarch)
1

Hello,

We are HyperTechLab Ltd., an Israeli electronics and embedded systems development company.

We are developing a product using the Sequans GM02SP and have encountered a problem after a firmware upgrade.

Module information:

GM02SP
IMEI: 016169005562199
S/N: 56H2349000016

The module is currently installed on an official Sequans evaluation board purchased from DigiKey.

The firmware history is important:

The module originally had LR8.2.0.3 / UE8.2.0.3. Cellular RF worked correctly.
We upgraded it to LR8.2.1.0 / UE8.2.1.0 using the normal SFU upgrade procedure. Cellular RF continued to work correctly.
We then performed a normal SFU upgrade using:

GP02RBAQ-DM_LR8.2.2.1-63493.dup

The upgrade completed, but immediately afterwards the module stopped detecting cellular networks.

Before this upgrade the module reliably detected NB-IoT cells at the same location.

After the upgrade, the modem remains at:

+CEREG: 2

AT+SQNMONI=9 returns ERROR, and AT+SQNINS=0 does not find cells/does not complete normally.

We tested both NB-IoT and LTE-M, with the same result.

We subsequently performed a full RASTER installation of LR8.2.2.1-63493. The RASTER procedure completed successfully, but RF operation was not restored.

We have now successfully downgraded the module back to UE8.2.1.0. The firmware runs normally, but the cellular problem remains: the module stays at +CEREG: 2 and does not detect the cells that it detected before the LR8.2.2.1 upgrade.

During RASTER/SFU we noticed that the tool backs up:

calibration
MIPI
configuration

We also have the resulting rf_calibration.cfg, rf_mipi.cfg and rf_configuration.cfg backup files.

Therefore, we suspect that persistent RF calibration, MIPI configuration, or another RF-related persistent configuration may have been modified during the first LR8.2.1.0 → LR8.2.2.1 upgrade, and that RASTER subsequently backed up and restored the already modified data.

Could you please advise:

Can an LR8.2.1.0 → LR8.2.2.1 upgrade modify persistent RF calibration, MIPI or RF configuration data?
Is there a procedure to restore the original factory RF configuration/calibration of this GM02SP?
Does Sequans retain the original factory calibration/configuration data associated with the module S/N or IMEI?
If necessary, can we provide our current rf_calibration.cfg, rf_mipi.cfg and rf_configuration.cfg files for verification?
Is there any additional diagnostic command or UART2 log that would help determine why the modem can no longer detect cells?

We can provide complete SFU/RASTER logs, UART2 boot/search logs and the RF configuration backup files.

Thank you,

HyperTechLab Ltd.
Israel

2

Hi Genady_Zeyfman:

The normal sfu upgrade will not touch or modify the calibration file. The calibration file and IMEI/SN might loss if raster upgrade is fail ( It backup identities, calibration file, rfconfig & mipi in the beginning and restore at the end) but this is not your case, so your file should be ok.

Could you try below AT commands and provide me the output?

AT+SQNCTM?

AT+SQNBANDSEL?

AT+CGSN?

AT+CFUN=5

AT+SQNHWCFG?

Please provide me the complete SFU/RASTER logs, UART2 boot/search logs and the RF configuration backup files.

3

Hello. Thanks for the answer!

AT+SQNCTM?
+SQNCTM: standard

AT+SQNBANDSEL?
+SQNBANDSEL: 0,3gpp-conformance,“”
+SQNBANDSEL: 0,att,“2,4,12”
+SQNBANDSEL: 0,docomo,“1,19”
+SQNBANDSEL: 0,kddi,“18,26”
+SQNBANDSEL: 0,standard,“1,2,3,4,5,8,12,13,17,18,19,20,25,26,28,66”
+SQNBANDSEL: 0,telstra,“3,28”
+SQNBANDSEL: 0,tmo,“2,4,5,12,66”
+SQNBANDSEL: 0,verizon,“13,4,5,12,17,20”
+SQNBANDSEL: 1,3gpp-conformance,“”
+SQNBANDSEL: 1,standard,“1,2,3,4,5,8,12,13,17,18,19,20,25,26,28,66,85”
+SQNBANDSEL: 1,telstra,“3,28”
+SQNBANDSEL: 1,verizon,“13”

AT+CGSN=1
+CGSN: “016169005562199”
AT+CGSN=2
+CGSN: “0161690055621919”
AT+CGSN=3
+CGSN: “19”

AT+SQNHWCFG?
+SQNHWCFG: fff_ffh: enable, polarity: normal
+SQNHWCFG: gpio31: enable, polarity: normal, direction: output, value: low
+SQNHWCFG: pwm0: disable
+SQNHWCFG: pulse0: disable
+SQNHWCFG: gpio32: enable, polarity: normal, direction: output, value: low
+SQNHWCFG: pwm1: disable
+SQNHWCFG: pulse1: disable
+SQNHWCFG: uart0_sin: enable
+SQNHWCFG: gpio12: disable
+SQNHWCFG: uart0_sout: enable
+SQNHWCFG: gpio13: disable
+SQNHWCFG: uart0_cts: enable
+SQNHWCFG: uart1_sin: enable
+SQNHWCFG: uart1_sout: enable
+SQNHWCFG: uart1_rts: enable
+SQNHWCFG: uart2_sin: enable
+SQNHWCFG: gpio15: disable
+SQNHWCFG: uart2_sout: enable
+SQNHWCFG: gpio16: disable
+SQNHWCFG: gpio17: disable
+SQNHWCFG: uart2_rts: disable
+SQNHWCFG: dcd: disable
+SQNHWCFG: gpio18: disable
+SQNHWCFG: uart2_cts: disable
+SQNHWCFG: dsr: disable
+SQNHWCFG: gpio19: enable, polarity: normal, direction: input, value: low
+SQNHWCFG: uart3_sin: disable
+SQNHWCFG: gpio20: enable, polarity: normal, direction: input, value: low
+SQNHWCFG: uart3_sout: disable
+SQNHWCFG: gpio21: enable, polarity: normal, direction: input, value: low
+SQNHWCFG: uart3_rts: disable
+SQNHWCFG: gpio22: enable, polarity: normal, direction: input, value: low
+SQNHWCFG: uart3_cts: disable
+SQNHWCFG: 32khz_clk_out: disable
+SQNHWCFG: gpio23: enable, polarity: normal, direction: input, value: low
+SQNHWCFG: i2c_sda: disable
+SQNHWCFG: gpio24: enable, polarity: normal, direction: input, value: low
+SQNHWCFG: i2c_scl: disable
+SQNHWCFG: gpio9: enable, polarity: normal, direction: input, value: low
+SQNHWCFG: spi_clk: disable
+SQNHWCFG: gpio7: enable, polarity: normal, direction: input, value: low
+SQNHWCFG: spi_mosi: disable
+SQNHWCFG: gpio8: enable, polarity: normal, direction: input, value: low
+SQNHWCFG: spi_miso: disable
+SQNHWCFG: gpio10: enable, polarity: normal, direction: input, value: low
+SQNHWCFG: spi_csn0: disable
+SQNHWCFG: gpio11: enable, polarity: normal, direction: input, value: low
+SQNHWCFG: spi_csn1: disable
+SQNHWCFG: sim0_data: enable
+SQNHWCFG: sim0_clk: enable
+SQNHWCFG: sim0_resetn: enable
+SQNHWCFG: gpio25: enable, polarity: normal, direction: input, value: low
+SQNHWCFG: sim1_data: disable
+SQNHWCFG: gpio26: enable, polarity: normal, direction: input, value: low
+SQNHWCFG: sim1_clk: disable
+SQNHWCFG: gpio27: enable, polarity: normal, direction: input, value: low
+SQNHWCFG: sim1_resetn: disable
+SQNHWCFG: wake0: disable
+SQNHWCFG: wake1: disable
+SQNHWCFG: wake2: disable
+SQNHWCFG: wake3: disable
+SQNHWCFG: wake4: disable
+SQNHWCFG: tx_ind: disable
+SQNHWCFG: gpio33: disable
+SQNHWCFG: ant_tune0: disable
+SQNHWCFG: gpio34: disable
+SQNHWCFG: ant_tune1: disable
+SQNHWCFG: gpio35: disable
+SQNHWCFG: status_led: disable
+SQNHWCFG: gpio1: disable
+SQNHWCFG: ps_status: enable
+SQNHWCFG: gpio2: disable
+SQNHWCFG: gpio28: disable
+SQNHWCFG: dtr: disable
+SQNHWCFG: gnss: enable
+SQNHWCFG: uart0_rts: enable
+SQNHWCFG: gpio14: disable
+SQNHWCFG: uart1_cts: enable
+SQNHWCFG: ring0: enable, polarity: inversed
+SQNHWCFG: sim0_detect: enable
+SQNHWCFG: gpio6: enable, polarity: normal, direction: output, value: low
+SQNHWCFG: pcm_txd: disable
+SQNHWCFG: gpio5: enable, polarity: normal, direction: output, value: low
+SQNHWCFG: pcm_fs: disable
+SQNHWCFG: gpio4: enable, polarity: normal, direction: output, value: low
+SQNHWCFG: pcm_clk: disable
+SQNHWCFG: gpio3: enable, polarity: normal, direction: output, value: low
+SQNHWCFG: pcm_rxd: disable
+SQNHWCFG: adc1: disable
+SQNHWCFG: uart0: enable, flowcontrol: rtscts, baudrate: 115200, format: 8 bits, parity: none, stopbits: 1, application: at
+SQNHWCFG: uart1: enable, flowcontrol: rtscts, baudrate: 921600, format: 8 bits, parity: none, stopbits: 1, application: at
+SQNHWCFG: uart2: enable, flowcontrol: unsupported, baudrate: 115200, format: 8 bits, parity: none, stopbits: 1, application: console
+SQNHWCFG: antennaTuning: disable
+SQNHWCFG: txIndicator: disable, threshold: 3000
+SQNHWCFG: jtag: enabled
+SQNHWCFG: lpm: enabled
+SQNHWCFG: wake0: disable
+SQNHWCFG: wake1: disable
+SQNHWCFG: wake2: disable
+SQNHWCFG: wake3: disable
+SQNHWCFG: wake4: disable
+SQNHWCFG: wakeRTS0: enable
+SQNHWCFG: wakeRTS1: enable
+SQNHWCFG: wakeSim0: enable, polarity: inversed
+SQNHWCFG: sim0: enable
+SQNHWCFG: sim1: disable

I would also like to clarify why I originally decided to upgrade the firmware.

With the original UE8.2.0.3 firmware, I encountered a reproducible problem when trying to put the modem into low-power/sleep mode. After completing an HTTP transaction and disconnecting the HTTP session, the modem would sometimes enter sleep normally, but quite often it crashed and rebooted instead.

+SYSSTART
AT+CFUN=1
+CEREG:
+CEREG: 1,“4B7E”,“031070CB”,9,“00000101”,“00000110”
AT+SQNHTTPCFG=0,“xxx.xxx.xxx.xxx”,80,0,“”,“”
OK
AT+SQNHTTPCONNECT=0
OK
AT+SQNHTTPQRY=0,0,“/text.txt”
OK
+SQNHTTPRING: 0,200,“text/plain”,50
AT+SQNHTTPRCV=0
<<<12345678901234567890123456789012345678901234567890
OK
AT+SQNHTTPDISCONNECT=0
OK
^EXIT: exception: 1 ITYPE: 0x30020 PC: 0x600000c2 EVA: 0x2aaaaaaa
^EXIT: TLB fill: TLB read protection (data) (data memory access)
^EXIT: 1) 1C3FD100
^EXIT: 2) 1C3A8442
^EXIT: 3) 1C20BF20
^EXIT: 4) 1C141C30
^EXIT: 5) 6000002A
^EXIT: 6) 60000008
^EXIT: 8.2.0.3 [60186] by robot-soft at 2023-11-29 18:15:00
^EXIT: Uptime: 53s
^EXIT: exception: 1 ITYPE: 0x30020 PC: 0x600000c2 EVA: 0x2aaaaaaa
+SYSSTART

GPB2308250008006.zip (2.7 KB)

4

I figured out the network registration issue. It appears that the new firmware does not work well when all supported bands are enabled. After restricting the NB-IoT band list to the bands actually used here, the modem finds the network and registers normally.

So the network issue is resolved.

However, the original problem with entering sleep mode is still present on UE8.2.2.1. The modem still crashes when it attempts to enter sleep.

I was able to reproduce the crash again and also downloaded the complete crash dump using SQN DM Light.

crashdump-2026-09-01-14h40m56.dmcd (395.4 KB)

[NSW_INFO] URC: +SQNHTTPRING: 0,200,“text/plain”,50,1

eem: Suspending…
New fatal context 0
exception: 3 ITYPE: 0x660060 PC: 0x600000c2 EVA: 0xaa0a231a
TLB misc: TLB read protection (data) (data memory access)

  1. 1C40FA0A
  2. 1C3B7F38
  3. 1C20F1D2
  4. 1C142FE8
  5. 6000002A
  6. 60000008
    [NSW_INFO] URC: ^EXIT: exception: 3 ITYPE: 0x660060 PC: 0x600000c2 EVA: 0xaa0a231a
    [NSW_INFO] URC: ^EXIT: TLB misc: TLB read protection (data) (data memory access)
    [NSW_INFO] URC: ^EXIT: 1) 1C40FA0A
    [NSW_INFO] URC: ^EXIT: 2) 1C3B7F38
    [NSW_INFO] URC: ^EXIT: 3) 1C20F1D2
    [NSW_INFO] URC: ^EXIT: 4) 1C142FE8
    [NSW_INFO] URC: ^EXIT: 5) 6000002A
    [NSW_INFO] URC: ^EXIT: 6) 60000008
    [NSW_INFO] URC: ^EXIT: 8.2.2.1 [63493] by robot-soft at 2025-10-06 14:43:35
    [NSW_INFO] URC: ^EXIT: Uptime: 102s
    [NSW_INFO] URC: ^EXIT: exception: 3 ITYPE: 0x660060 PC: 0x600000c2 EVA: 0xaa0a231a
    [NSW_INFO] URC: ^EXIT: TLB misc: TLB read protection (data) (data memory access)
    [NSW_INFO] URC: ^EXIT: Task: eemThread(00208F78)
    [NSW_INFO] URC:
5

Hi Genady_Zeyfman:

Thanks for the information and update, yes the full bands scanning time is too long, specially for NBIoT. Usually customers change the config to limit the bands they are really used.

+SQNBANDSEL: 0,standard,“1,2,3,4,5,8,12,13,17,18,19,20,25,26,28,66”
+SQNBANDSEL: 1,standard,“1,2,3,4,5,8,12,13,17,18,19,20,25,26,28,66,85”

Regarding the fatal message after eem: Suspending… , is this the test done with NB-IoT mode?

eem: Suspending…
New fatal context 0
exception: 3 ITYPE: 0x660060 PC: 0x600000c2 EVA: 0xaa0a231a
TLB misc: TLB read protection (data) (data memory access

Best regards,

Eros

6

Yes . NB-IoT mode. I tested SIM cards from two operators. The result is the same.