zephyr: mqtt_publisher: Unable to connect properly on EC21 modem with bg9x driver

Describe the bug I’m working on to port the bg9x driver for EC21. I’ve checked the TCP/IP AT commands of BG96 & EC21 and they are identical. I tried to run the mqtt_publisher example, but it doesn’t work.

I traced a bit and found that it connected with my MQTT broker, but disconnected immediately after that.

This is the reading of the AT commands going into the modem:

AT+QIOPEN=1,0,"TCP","server_ip_addr",1883,0,0
AT+QISEND=0,30
MQTT<zephyr_publisherAT+QICLOSE=0

I can see that the modem received something from the server, likely the CONNACK from the MQTT broker:

+QIURC: "recv",0

But somehow offload_read and offload_recvfrom never get called therefore AT+QIRD isn’t sent to read the buffer out. The application didn’t progress further from connecting the broker. For some reason when the modem receives something: on_cmd_unsol_recv -> modem_socket_data_ready, the sock->is_waiting is always false.

To Reproduce Steps to reproduce the behavior:

Build the mqtt_publisher sample on a board with EC21 modem, see “Additional context”
See error

Expected behavior Publishes successfully to my MQTT broker.

Impact Unable to progress with telemetry related task using MQTT and planned work to improve the driver.

Logs and console output

Zephyr’s log

[00:00:02.000,000] <inf> modem_quectel_bg9x: Setting Modem Pins
[00:00:04.751,000] <inf> modem_quectel_bg9x: ... Done!
[00:00:04.751,000] <inf> modem_quectel_bg9x: Waiting for modem to respond
[00:00:13.792,000] <inf> modem_quectel_bg9x: Manufacturer: Quectel
[00:00:13.844,000] <inf> modem_quectel_bg9x: Model: EC21
[00:00:13.915,000] <inf> modem_quectel_bg9x: Revision: EC21EFAR06A01M4G
[00:00:13.969,000] <inf> modem_quectel_bg9x: IMEI: 012345678901234
[00:00:14.046,000] <inf> modem_quectel_bg9x: RSSI: -1000
[00:00:16.051,000] <inf> modem_quectel_bg9x: RSSI: -1000
[00:00:18.054,000] <inf> modem_quectel_bg9x: RSSI: -1000
[00:00:20.057,000] <inf> modem_quectel_bg9x: RSSI: -55
uart:~$ *** Booting Zephyr OS build zephyr-v2.5.0-2162-g365145aa971c  ***
[00:00:22.058,000] <inf> modem_quectel_bg9x: Network is ready.
[00:00:22.079,000] <inf> net_config: Initializing network
[00:00:22.079,000] <inf> net_mqtt_publisher_sample: attempting to connect:
[00:00:22.157,000] <inf> modem_quectel_bg9x: AT+QIOPEN: 0
[00:00:22.211,000] <inf> modem_quectel_bg9x: Data Receive Indication for socket: 0
[00:00:32.216,000] <inf> net_mqtt_publisher_sample: MQTT client disconnected -53
[00:00:32.286,000] <inf> modem_quectel_bg9x: AT+QIOPEN: 0
[00:00:32.328,000] <inf> modem_quectel_bg9x: Data Receive Indication for socket: 0
[00:00:42.334,000] <inf> net_mqtt_publisher_sample: MQTT client disconnected -53
[00:00:42.399,000] <inf> modem_quectel_bg9x: AT+QIOPEN: 0
[00:00:42.443,000] <inf> modem_quectel_bg9x: Data Receive Indication for socket: 0
[00:00:52.449,000] <inf> net_mqtt_publisher_sample: MQTT client disconnected -53
[00:00:52.452,000] <inf> modem_quectel_bg9x: RSSI: -61
[00:00:52.519,000] <inf> modem_quectel_bg9x: AT+QIOPEN: 0
[00:00:52.561,000] <inf> modem_quectel_bg9x: Data Receive Indication for socket: 0

AT commands:


RDY
ATE1
OK
ATH
OK
AT+CMEE=1
OK
AT+CGMI
Quectel

OK
AT+CGMM
EC21

OK
AT+CGMR
EC21EFAR06A01M4G

OK
AT+CGSN
1234567890123

OK
AT+QICSGP=1,1,"internet","", "",1
OK
AT+CSQ
+CSQ: 99,99

OK
AT+CSQ
+CSQ: 99,99

OK
AT+CSQ
+CSQ: 99,99

OK
AT+CSQ
+CSQ: 30,99

OK
AT+QIACT=1
OK
AT+QIOPEN=1,0,"TCP","X.X.X.X",1883,0,0
OK

+QIOPEN: 0,0
AT+QISEND=0,30
> MQTT<zephyr_publisher
SEND OK

+QIURC: "recv",0
AT+QICLOSE=0
OK
AT+QIOPEN=1,0,"TCP","X.X.X.X",1883,0,0
OK

+QIOPEN: 0,0
AT+QISEND=0,30
> MQTT<zephyr_publisher
SEND OK

+QIURC: "recv",0
AT+QICLOSE=0
OK
AT+QIOPEN=1,0,"TCP","X.X.X.X",1883,0,0
OK

+QIOPEN: 0,0
AT+QISEND=0,30
> MQTT<zephyr_publisher
SEND OK

+QIURC: "recv",0
AT+QICLOSE=0
OK

Environment (please complete the following information):

OS: Windows 10
Toolchain gnuarmemb
Zephyr OS build zephyr-v2.5.0-2162-g365145aa971c

Additional context So far I only found that it is required to increase the wait for the AT+QICLOSE in socket_close() or else it fails on EC21

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 22 (8 by maintainers)

Most upvoted comments

I’m not familiar with the modem_socket.c code, but the sock->packet_sizes array seems used everywhere. Having null values doesn’t seem’s to be a good idea.

@XavierChapron I think the modem_socket.c is fine, the issue should be at the driver. The bg9x driver has nothing to set the initial inbound packet size

I’ve added something to update the packet size on reception and now the modem_socket side of things seemed to work properly

ycsin on Apr 20, 2021

You’re receiving a URC indicating that the modem has received data for socket 0. Once this is done, the modem_socket_poll should unblock (with success) and your application would trigger a read from the modem. This will eventually call up on_cmd_sockread_common in quectel-bg9x.c which performs the actual read from modem. Seems that that’s not happening.

Can you debug your main application (mqtt_publisher) and check what the call to wait returns and if mqtt_input is actually invoked ? https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/mqtt_publisher/src/main.c#L381

This driver has been tested been mqtt publisher multiple times before.

bwasim on Apr 15, 2021