BG96 dead after TCP send

IoT Modules LPWA Module
1

I have a device using the BG96-MA (firmware BG96MAR03A05M1GA). My firmware is working very well normally, it opens a TCP socket, sends some data, reads a response and closes the socket. However, there have been two instances on two different modems where a certain message (not the same) has caused the BG96 to stop responding to any commands.

I have captured this with an oscilloscope:

> AT+QIOPEN=1,0,"TCP","url-redacted",1234
< OK
< +QIOPEN: 0,0
> AT+QISEND=0,517
< >
send lots of data
< SEND OK
> AT+QISEND=0,0
nothing after 120 seconds, no response to any command after this (tried AT+QIRD and AT+QISTATE).

Normally the AT+QISEND command responds immediately.
I have the device with this modem and can reproduce this behaviour. If a different message is sent the modem works fine, so it seems to be somehow related to the contents being sent.

Any help would be much appreciated.

2

Also worth noting, the server successfully receives the message and sends it’s response.

3

I used a different modem to send the exact same payload and it worked fine.

4

I modified my firmware to send the TCP payload in 50 byte chunks and that avoids the problem. I don’t see why that should make any difference, the command is supposed to accept up to 1460 bytes and even responds with “SEND OK”.

5

You means after updating the firmware that the problem is resolved?

6

I modified my firmware (not the modem firmware) to send the TCP payload in 50 byte chunks rather than 517 bytes in one go. I suspect there is a bug in the BG96 firmware, it should be able to send 517 bytes in one go. It even responds with ‘SEND OK’, indicating it has received the 517 bytes, but it is dead after that.

7

This problem has reappeared. Again, it appears to be a problem in the BG96 firmware. The message contents does not produce the same problem in another modem.

I have an oscilloscope capture of the UART comms.

Open socket:

> AT+QIOPEN=1,0,"TCP","url-redacted",1234
< OK
< +QIOPEN: 0,0

Send 29 byte header first, then 50 byte blocks until the final block of 41 bytes. These all succeed with SEND OK response.

> AT+QISEND=0,50
< >
> [50 bytes]
< SEND OK

After sending is finished, the command to check sending progress gets no response.

> AT+QISEND=0,0

The command is repeated several times with 3 second timeout. Eventually it times out and the application firmware sends other commands, but the BG96 will never respond.

This is a really big problem because we can’t recover from this. The modem has to be power cycled and ends up doing the same thing again.

Is there any known errata for this bug? The firmware is BG96MAR03A05M1GA.

8

I’ve found that adding a 1 second delay before AT+QISEND=0,0 solves the problem. That indicates there is a race condition within the BG96 firmware. The modem often sends a +QIURC: "recv", 0 URC during that delay, because the server is responding to the completed message.

9

A Quectel FAE has reproduced and confirmed this bug. The delay seems to be a valid workaround.

In the BG96MAR03A05M1GA firmware, we found there is a check in the TCP send path to determine whether the socket is an SSL socket. When AT+QISEND=0,0 is issued immediately after SEND OK with no gap, the firmware misidentifies the plain TCP socket as an SSL socket, enters the SSL path, and then waits on a callback that is never raised, hence the freezing.

Your workaround of adding a delay before AT+QISEND=0,0 is a valid interim measure, as it avoids the timing condition that triggers this.