ERROR with AT+KHTTPPOST command on RC7620

Hi,

I’m using an RC7620 module in a device.

I’m using a UART with activated flow control to communicate with it from a µC.

The module version is 00.08.24.02.

I’m having trouble with the AT+KHTTPPOST command.

Sometimes, when data is streamed to the module in 512-byte packets, unexpected behaviour occurs.

The module returns an '“ERROR” without any details when it receives “–EOF–Pattern–” and then remains silent for quite some time.

Server side, only the beginning of the data is received, which is never the same size but always on exact ko size.

AT+CMEE=1 is sent and acknowledged OK by the module.

I tried “AT+KURCCFG=“HTTP”,1,1” but this did not help.

Below is a list of the commands sent to the RC7620:

Commands Answer from the module
AT+CPWROFF OK
AT
AT OK
ATE0 OK
AT+CGSN
AT+KGSN=3 “+KGSN: CN…” OK
AT+KURCCFG=“HTTP”,0,0 OK
AT+KURCCFG=“HTTPS”,0,0 OK
AT+KURCCFG=“UDP”,0,0 OK
AT+GMR SWI9X07H_00.08.24.02 f90cbd jenkins 2022/03/21 03:47:54
AT+KSRAT=5 OK
AT+CCLK? "+CCLK: “25/09/24,17:18:49+08” OK
AT&W OK
AT+KCNXCFG=1,“GPRS”,“internet.swir” OK
AT+KCNXTIMER=1,30,4,0,30 OK
AT+KCNXPROFILE=1 OK
Some times passes by
AT+KCERTSTORE=0 CONNECT
-----BEGIN CERTIFICATE----- (…) OK
AT+KHTTPCFG=1,“proxy-server-url”,443,2,0 “+KHTTPCFG: 4” OK
AT+KHTTPCNX=4 OK
AT+KHTTPHEADER=4 CONNECT
X-Eqm-Api-Key: kTCl/(…) OK
AT+KHTTPPOST=4,“api_1_url” CONNECT
{JSON} HTTP/1.1 200 OK (…)
AT+KHTTPHEADER=4 CONNECT
X-Eqm-Api-Key: kTCl/(…) OK
AT+KHTTPPOST=1,“api_2_url” CONNECT
{JSON} HTTP/1.1 201 OK (…)
AT+KHTTPCLOSE=4 OK
AT+KHTTPDEL=4 OK
AT+KCERTSTORE=0 CONNECT
-----BEGIN CERTIFICATE----- (…) OK
AT+KHTTPCFG=1,“proxy-server-url”,443,2,0 “+KHTTPCFG: 4” OK
AT+KHTTPCNX=4 OK
AT+KHTTPHEADER=4 CONNECT
X-Eqm-Api-Key (…) OK
AT+KHTTPPOST=4,“api_post_url” CONNECT
{JSON… → size 512b
send 190 packets of 512 bytes
…JSON} → size 512b ERROR
AT+KHTTPCLOSE=4
AT+KHTTPCLOSE=4
AT+KHTTPDEL=4
AT+KHTTPDEL=4
AT+KCERTSTORE=0
AT+KCERTSTORE=0 ERROR
AT+KCERTSTORE=0
AT+KCERTSTORE=0
AT
AT
AT OK
ATE0 OK

I would appreciate some assistance.

Does it work with latest firmware?

Did you try with at+ksleep=2 ?

does it work without using SSL?

I’m struggling a bit with the firmware update…

Command send during the device initialisation (and acknoledged OK by the module.):

AT+CMEE=1

AT+KSLEEP=2

AT!MUXMODE=1

AT!MAPUART=1

AT+IFC=2,2

what is the problem of upgrading firmware?

does it work after setting at+ksleep=2 ?

does it work without using SSL?

The module is not routed to be updated directly from a computer and our µc doesn’t have enough space left for the firmware to use AT command.

I think your’re already helping me with this subject : forum.sierrawireless.com

It does not work with at+ksleep=2.

Tests without SSL will be down latter today. I will keep you updated on the results.

You can also upgrade with airvantage platform by FOTA

Test without SSL failed as well :frowning:

The server received 96kB from a total of 529.2 kB. A second try was maid a few minutes latter and succeeded (same behavior with SSL, it works fine sometimes, but othertimes it fails and succeeds after some retries).

Test with release 10 is not tested yet. It should tested in the next day.

does it help if you disable the EDRX mode by AT+CEDRXS=0 ?

I saw this can help some issue with WP77 module:

So several tests have been made.

The command AT+CEDRXS=0 returns en ERROR without details (send it before connecting the device to the network)

For the test of the release 10, the same issue occured…
The module responds ERROR at the reception of --EOF–Pattern-- after the AT+KHTTPPOST responded CONNECT

Can you test with +ktcp command with a simple tcp server?

Is there a tool from sierra that could be used to see the exact trafic leaving the module ?

During some tests this weekend, the module returned an “ERROR” but the server received the entirety of the post data.

Logs from the server show that a 200 error was sent.

is this only happening in HTTP protocol?
Can you test with +ktcp command with a simple tcp server?

To capture the wireshark log of the module, you need to contact distributor to get a specific filter and capture the DM log and ask distributor to convert it to wireshark log.

It’s happening for HTTP and HTTPS protocol.

Server is not setup for tcp request (I was told)

By distributor, you mean the one selling the module, the one producing the module or the one in charge of the network ?
Or the SIM card ?

probably you need to set up your own TCP server to get more clue of this issue.

“Distributor” means the company that sells the RC76 module to you