HL7810 Embedded MQTT/TLS Instability Across Firmware Versions
Suggested subject
HL7810 5.7.2.0 resets during AT+KMQTTCNX; 5.5.14.0 disconnects after inbound QoS 1 PUBLISH
Product and test environment
- Module: Sierra Wireless / Semtech HL7810
- Current firmware:
HL7810.5.7.2.0-24.10.1.FreeRTOS.w43HL78xx.5.7.2.0.RK_03_02_00_00_43621_001.20260413ATI3confirmation:HL7810.5.7.2.0- Build date: 2026-04-13
- Legato RTOS / atSwi version:
24.10.1.FreeRTOS.w43(this is not modem firmware 5.7.2.1) - Previously tested firmware:
HL7810.5.5.14.0-23.12.0.FreeRTOS.w49HL7810.5.4.10.0
- Host MCU: Raspberry Pi Pico 2 W / RP2350
- UART: 115200 baud, 8N1
- AT command terminator: carriage return (
\r) only - UART flow control: disabled with
AT&K0andAT+IFC=0,0 - Hardware limitation: the current PCB does not route CTS/RTS for hardware flow control
- Mobile network registration: successful (
+CEREG: 5) - Packet service: attached and PDP context successfully activated
- MQTT broker: EMQX 6.2.1, TLS listener on TCP port 8883
- MQTT protocol version: 3.1.1 (
version=4) - TLS: TLS 1.2 with server-certificate verification
- Root certificate: ISRG Root X2, 790 bytes, stored in root certificate slot 0
- MQTT payloads used in this test: 2 to approximately 60 bytes
All credentials, IMSI values, client identifiers, and public host names can be provided privately if required. They have been redacted from this report.
Primary problem on firmware 5.7.2.0
On firmware 5.7.2.0, the embedded MQTT client cannot complete a secure MQTT connection. AT+KMQTTCNX=1 is accepted, but no successful or failed +KMQTT_IND is returned. Instead, the module appears to restart an internal subsystem, drops the packet-data/MQTT state, and re-registers on the mobile network.
Expected result
According to the Rev. 29 AT Command Reference Guide, the expected sequence is similar to:
AT+KMQTTCNX=1
+KMQTTCNX: 1
OK
+KMQTT_IND: 1,6
+KMQTT_IND: 1,1
+KMQTT_IND: 1,1 should indicate that CONNACK was received from the broker.
Actual result
The following is a representative redacted trace:
[13:02:41.477] AT TX AT+KMQTTCNX=1\r
[13:02:41.493] +KMQTTCNX: 1
[13:02:50.274] <NUL>
[13:02:50.277] OK
[13:02:51.158] +WDSI: 0
[13:02:53.683] +CEREG: 2
[13:02:54.379] +CEREG: 0
[13:02:54.391] +CEREG: 2
[13:02:57.778] +CEREG: 5,"<TAC>","<CELL_ID>",7
No +KMQTT_IND: 1,6, +KMQTT_IND: 1,1, or +KMQTT_IND: 1,0 is received. The unexpected NUL byte, +WDSI: 0, loss of registration, and subsequent re-registration occur repeatedly after the connection command.
The same behavior was reproduced with MQTT cipher profile 0 and profile 7.
Minimal reproduction procedure on 5.7.2.0
The following sequence was performed after a full profile reset and module reboot. Sensitive parameters are shown as placeholders.
AT&F
AT&K0
AT+IFC=0,0
ATE0
AT+CMEE=1
AT+IPR=115200
AT&W0
AT&W1
AT+CFUN=0,1
After mobile-network registration:
AT+KCERTSTORE=0,790,0
<exactly 790 bytes of the ISRG Root X2 certificate>
AT+KCNXCFG=1,"GPRS","<APN>","",""
AT+KCNXUP=1
The PDP activation completes successfully:
OK
+KCNX_IND: 1,1,0
TLS and MQTT configuration:
AT+KSSLCFG=0,3
AT+KSSLCFG=2,0
AT+KSSLCRYPTO=0,8,3,25392,12,4,1,0
AT+KMQTTCFG=1,1,"<BROKER_HOST>",8883,4,"<CLIENT_ID>",120,0,0,"","",0,0,"<USERNAME>","<PASSWORD>",0
AT+KMQTTCFG?
AT+KMQTTCNX=1
The configuration readback confirms secure MQTT, the expected broker and port, MQTT 3.1.1, keep-alive 120, and clean-session setting 0. The failure then occurs exactly as shown in the trace above.
The same failure was also reproduced with:
- Clean-session settings 0 and 1
- An empty MQTT username and password
- Cipher profiles 0 and 7
- A completely empty MQTT session table before configuration
- All certificate slots deleted and the root certificate freshly written
- Both saved AT profiles reset and saved again
Layer-isolation results on 5.7.2.0
The following lower layers were tested separately and worked:
- SIM ready and LTE registration
- Packet attach and PDP activation
- DNS resolution and assigned IPv4/gateway/DNS information
- Plain TCP connection to the broker TLS port
- Raw TLS socket handshake to the same server using the same TLS/cipher configuration
- Server certificate validation
The broker host successfully negotiated TLS 1.2 with:
ECDHE-ECDSA-AES256-GCM-SHA384
During AT+KMQTTCNX=1, the EMQX server showed:
- No connected client with this client ID
- No corresponding authentication request
- No established TCP connection observed on port 8883 during the test interval
This suggests that the failure happens inside the HL7810 embedded MQTT/TLS path before MQTT CONNECT/CONNACK reaches the broker.
For comparison, a non-secure MQTT configuration sent to the TLS-only listener failed normally with:
+CME ERROR: 907
+KMQTT_IND: 1,0
It did not trigger the internal restart/re-registration sequence.
Results on firmware 5.5.14.0
Firmware 5.5.14.0 behaved differently and was substantially more usable:
- Secure MQTT connection completed with
+KMQTT_IND: 1,1 - SUBSCRIBE completed with
+KMQTT_IND: 1,2 - QoS 1 outbound PUBLISH completed with
+KMQTT_IND: 1,4 - Configuration DATA was received successfully
- General AT commands remained responsive after inbound QoS 0 DATA
However, an inbound PUBLISH delivered to the module at QoS 1 caused the MQTT connection to close immediately after +KMQTT_DATA. This was reproduced with:
- The normal configuration payload
- A one-byte scalar payload
- A diagnostic loopback topic
The payload content and topic length did not change the result.
The following mixed-QoS configuration was stable in repeated tests:
- Configuration SUBSCRIBE requested at QoS 0
- Configuration response delivered at QoS 0
- Configuration-request PUBLISH sent at QoS 1
- Telemetry PUBLISH sent at QoS 1
This combination allowed repeated config DATA reception while keeping the session and AT interface responsive.
Earlier behavior on firmware 5.4.10.0
On firmware 5.4.10.0, the first MQTT request and inbound config DATA could succeed, but a subsequent MQTT control command could become unresponsive for approximately 168 to 216 seconds. Later responses included:
+CME ERROR: 907
+CME ERROR: 910
+KMQTT_IND: 1,0
The same type of stall was reproduced after DATA with PUBLISH, CLOSE, and session-query attempts. Session separation did not prevent it.
Additional troubleshooting already performed
- Used a minimal Pico firmware containing only modem power-up, certificate injection, USB serial, UART forwarding, and manual AT input
- Removed FreeRTOS sensor tasks, LCD logic, periodic MQTT tasks, and concurrent modem access from the reproduction
- Waited for each AT response and added a one-second quiet period before the next command
- Kept the initial session-reset sequence separate from the delayed command path
- Tested QoS 0 and QoS 1 combinations
- Tested short constant payloads including
{},3, and[-7,-10] - Reduced the EMQX maximum MQTT packet size from 1 MB to 1 KB
- Increased the broker idle timeout to 120 seconds
- Tested one MQTT session and separate sessions for different publishes
- Tested immediate CLOSE/DEL after DATA; the commands also stalled on the older firmware
- Confirmed complete
+KMQTT_DATAtermination, including trailing CR/LF - Confirmed that direct raw TLS to the same host works
- Confirmed that the current 5.7.2.0 failure remains after a factory-profile reset
AT error-code interpretation used
The following definitions are taken from the Rev. 29 AT Command Reference Guide:
- 907: Generic error
- 910: Bad session ID
- 922: Invalid session state
- 924: Session busy; retry later
- 931: Invalid parameter length
Rev. 29 shows +KMQTT_IND: <session_id>,6 in the KMQTTCNX example, but the MQTT status table defines only values 0 through 5. We therefore treat status 6 only as an undocumented intermediate indication and wait for status 1 or a terminal failure.
Questions for Sierra Wireless / Semtech
- Is there a known defect in HL7810 firmware 5.7.2.0 where secure
AT+KMQTTCNXrestarts the internal data/MQTT subsystem before TCP/MQTT CONNECT reaches the broker? - Does HL7810 firmware 5.7.4.0 contain a fix for this MQTT/TLS behavior?
- Is the NUL byte followed by
OK,+WDSI: 0, and LTE re-registration evidence of an internal application crash or watchdog reset? Is there a command to retrieve the reset reason, crash dump, or MQTT/TLS diagnostic log? - What is the documented meaning of
+KMQTT_IND: <session_id>,6in Rev. 29? - Is the inbound QoS 1 disconnect immediately after
+KMQTT_DATAa known limitation or defect in firmware 5.5.14.0? - Is hardware RTS/CTS mandatory for the embedded MQTT/TLS command path even when the certificate is only 790 bytes and MQTT payloads are below 80 bytes? Our current hardware cannot use RTS/CTS, but raw TLS succeeds.
- If 5.7.4.0 cannot be used, is downgrading an HL7810 from 5.7.2.0 to the previously tested 5.5.14.0 officially supported? Are there required intermediate versions, bootloader constraints, or post-downgrade factory-reset steps?
AirVantage downgrade limitation
We would like to downgrade this module from firmware 5.7.2.0 to the previously tested firmware 5.5.14.0. However, AirVantage FOTA does not provide or allow a downgrade to 5.5.14.0 for this module.
The HL7810 is permanently mounted on our production PCB. The PCB does not expose a USB or firmware-download interface that can be connected to a PC, so we cannot use a Windows/Linux one-click installer, a direct USB update tool, or another local recovery method. The module remains controllable through its normal AT UART, but AirVantage FOTA is the only firmware upgrade or downgrade method available on this hardware.
Please make firmware 5.5.14.0, or the required intermediate downgrade package, available to this specific HL7810 through AirVantage FOTA. If an AirVantage downgrade is not supported, please provide an AirVantage FOTA update to a firmware version that fixes this MQTT/TLS issue, such as 5.7.4.0 if the fix is included there.
Requested assistance
Please confirm whether this is a known firmware regression and recommend one of the following:
- A configuration or diagnostic procedure that allows secure embedded MQTT to work on 5.7.2.0
- An AirVantage FOTA update to 5.7.4.0 that specifically fixes this behavior
- An AirVantage FOTA downgrade path to 5.5.14.0, including any required intermediate version
We can provide the complete timestamped UART log, exact firmware-update package name and checksum, broker-side connection logs, and unredacted MQTT parameters through a private support channel.