ubxlib: Continuous UMQTTER 13,0 Error Loop and Improper Shutdown Behavior (SARA-R422M8S)

Hi Rob, Upon losing internet connection on my device, regardless of whether it’s due to antenna disconnection or forced disconnection, the device starts throwing UMQTTER error code 13,0, which then transitions to 13,50 or 13,34, indicating a normal behavior. However, upon re-establishing the connection, the system enters an error loop where it fails to connect, consistently throwing UMQTTER error code 13,0. Occasionally I noticed a discrepancy between the actual connection status and the one identified by the internal callbacks (network is up but it is detected as down). This behavior is reproducible consistently.

Furthermore, I’ve observed that the module fails to shut down properly. After every shutdown attempt (with AT commands), the UART pins on the ESP32 side remain active, causing a current leak into the u-blox module. As a consequence the ublox module outputs 0.7v-1.1v not allowing a proper shutdown procedure. I patched this issue by resetting the gpios on the microcontroller’s side but I need to understand if there’s an hardware issue causing it or if it’s a library bug.

Device: [ESP32S3]
Module: [SARA-R422M8S]
Environment: [ESP-IDF]

Serial output upon reconnection:

U_CELL_PWR: powering on.
AT
AT
AT
AT
AT
AT

OK
ATE0
AT

OK
AT+CMEE=2
ATE0

OK

OK

OK

OK
AT+UDCONF=1,0

OK
ATI9

00.12,A00.00

OK
AT&C1

OK
AT&D0

OK
AT+UCGED=2

OK
AT&K3

OK
AT+UPSV=4

OK
AT+UPSMR=1

OK
AT+CPSMS?

+CPSMS:0,,,"01100000","00000000"

OK
AT+CEDRXS?

+CEDRXS:

OK
AT+UMNOPROF?

+UMNOPROF: 100

OK
AT+UGPRF?

+UGPRF: 2,0,""



OK
AT+CFUN=4

OK
U_CELL_NET: preparing to register/connect...
AT+CREG=2

OK
AT+CGREG=2

OK
AT+CEREG=4

OK
AT+CIMI

295050903238865

OK
U_CELL_NET: user-specified APN is "em".
AT+CGDCONT=1,"IP","em"

OK
U_CELL_NET: setting automatic network selection mode...
AT+COPS?

SARA-R422M8S-00B-00

ERROR

+COPS: 0

OK
AT+CFUN=1

OK
AT+CREG?

+CREG: 2,0

OK
0: NReg
AT+CGREG?

+CGREG: 2,4

OK
0: OoC
AT+CEREG?

+CEREG: 4,0

OK
0: NReg
AT+CREG?

+CREG: 2,0

OK
0: NReg
AT+CGREG?

+CGREG: 2,4

OK
0: OoC
AT+CEREG?

+CEREG: 4,0

OK
0: NReg
AT+CREG?

+CREG: 2,0

OK

+CREG: 2

+CEREG: 2,,,,,,,,
0: NReg
-1: Search
-1: Search

+CREG: 5,"4E62","00006BE6",3


3: RegR
AT+CGREG?

+CGREG: 2,2

OK
0: Search
AT+CEREG?

+CEREG: 4,4

OK
0: OoC
AT+CREG?

+CREG: 2,5,"4E62","00006BE6",3

OK
3: RegR
AT+CGREG?

+CGREG: 2,2

OK
3: Search
AT+CEREG?

+CEREG: 4,4

OK
3: OoC
AT+CREG?

+CREG: 2,5,"4E62","00006BE6",3

OK
3: RegR
AT+CGREG?

+CGREG: 2,2

OK
3: Search
AT+CEREG?

+CEREG: 4,4

OK
3: OoC
AT+CREG?

+CREG: 2,5,"4E62","00006BE6",3

OK
3: RegR
AT+CGREG?

+CGREG: 2,2

OK
3: Search
AT+CEREG?

+CEREG: 4,4

OK
3: OoC
AT+CREG?

+CREG: 2,5,"4E62","00006BE6",3

OK
3: RegR

+CGREG: 5,"4E62","00006BE6",3,"46"
3: RegR
AT+COPS=3,0

OK
AT+COPS?

+COPS: 0,0,"vodafone IT",3

OK
AT+CGATT?

+CGATT: 1

OK
AT+CGACT?

ERROR
AT+CGACT=1,1

+CGACT: 1,0

OK
AT+CGACT?

OK
AT+CGACT=1,1

OK
AT+CGACT?

+CGACT: 1,1

OK
AT+UPSD=0,0,0

OK
AT+UPSD=0,100,1

OK
U_CELL_NET: connected after 15 second(s).
AT+UMQTT=2,"cssiot01.eurac.edu",1883



OK
AT+CGSN

355438111885391

OK
AT+UMQTT=0,"355438111885391"



OK
AT+UMQTT=10,120



OK
U_CELL_MQTT: trying to connect...
AT+UMQTTC=1



OK
U_CELL_MQTT: waiting for response for up to 120 second(s)...
AT+UMQTTER

+UMQTTER: 13,0



OK
U_CELL_MQTT: error codes 13, 0.
AT+UMQTTER

+UMQTTER: 13,0



OK
AT+UMQTTER

+UMQTTER: 13,0



OK
U_CELL_MQTT: error codes 13, 0.

About this issue

Original URL
State: closed
Created 4 months ago
Comments: 18 (11 by maintainers)

Most upvoted comments

Hey Rob,

It is certainly not necessary: the module operation will fail anyway if the network status is such that the operation cannot succeed and calling into a ubxlib API function from a callback out of the ubxlib API can lead to problems: some API functions involve AT commands that have URC-style responses that get put into a callback queue, a queue which your callback may already be in, leading to the API locking up. Better just to use the callback as your application’s timeout/watchdog/abandon-that-operation-please control based on information local to it.

The +UMQTTER: 13,0 was related to the callback, Now that I set it to false I’m not experiencing the issue anymore.

That is very strange indeed, seems as though the module is actively able to draw power from the UART IO lines. The pulse on the PWR_ON HW pin is a toggle (i.e. if the module is off it switches it on, if the module is on it switches it off), which is why the ubxlib code always checks if the module is up first by bouncing AT off it; if responsiveness to an AT check isn’t reliable proof that the module is powered on or off, things are going to get very confused indeed. Not sure I can advise you how to proceed on how HW issues though, not really my area I’m afraid.

About this point, I think neither of us is actually supposed to solve it.

Thanks again for your time,

Take care

tommas0serafin on Feb 21, 2024

Unfortunately the hardware failed me, I’ll come back tomorrow with more detailed logs (I’ll add what you suggested).

To clarify the last point, the antenna is reconnected while the module is powered off (but the micro isn’t) so the whole log you read includes only the section with the antenna on.

tommas0serafin on Feb 19, 2024