HTTPS requests on A9G via AT commands fail after 7 requests; HTTP works fine

Solution for HTTPS requests on A9G via AT commands fail after 7 requests; HTTP works fine
is Given Below:

I’m using AT commands to communicate with an Ai-Thinker A9G chip from an ESP8266, as part of a GPS tracker unit. It works fine to start with, then HTTPS requests start failing after sending 7 or 8 successfully. However, it’s still fine making HTTP requests.

What could be causing HTTPS requests to fail after the first 7 or 8, when HTTP requests work just fine?


Details…

As the unit starts up, I’m using the following to establish the GPRS connection:

AT+CGREG=1
> OK

AT+CGATT=1
> +CGATT:1
> OK

AT+CGDCONT=1,"IP","data.uk" // APN for 1pmobile
> OK

AT+CGACT=1,1
> OK

AT+CGACT?
> +CGACT: 1, 1
> OK

Then to publish the location every N minutes, the following:

AT+HTTPPOST="https://<URL>","application/x-www-form-urlencoded","arg1=val1&arg2=val2&..."

That works the first 7 or 8 times, after which all HTTPS requests fail with the following message (copied exactly as sent from the A9G chip, including the firmware’s spelling error):

+CME ERROR: parameters are invalid
failure, pelase check your network or certificate!

After the HTTPPOST commands start failing I’ve tried the following status checks but everything suggests the chip is in a good state and online still:

AT+CIPSTATUS
> +CIPSTATUS:
> STATE:IP INITIAL

AT+CGACT?
> +CGACT: 1, 1
> OK

AT+CGREG?
> +CGREG: 1, 1
> OK

AT+CGDCONT?
> +CGDCONT:1,"IP","data.uk","<IP address>",0,0
> OK

I’ve also tried:

  • Sending the requests back-to-back or 5 minutes apart – no change in behaviour, it still fails after 7 or 8 requests, regardless of time elapsed.
  • Swapping to a different SIM card and updating the APN specified in CGDCONT – no change.
  • Deactivating the network connection with AT+CGACT=0,1, AT+CGATT=0, AT+CGREG=0 then re-enabling it – no change.
  • Making AT+HTTPGET requests instead of HTTPPOST – no change.
  • Restarting the A9G chip – this gives me another 7 or 8 requests, then the pattern repeats.
  • Making requests to an HTTP URL instead of HTTPS – as noted, these work just fine.

Annoyingly, documentation for the A9/A9G chip is thin on the ground. Much of it is in Chinese-language PDFs that don’t play nicely with Google Translate. These are the most useful links I’ve found to piece together what I have above:

In the end I contacted the chip manufacturer, explained the problems I’ve had and suggested there might be a bug in the firmware. They responded and confirmed that was the case, and suggested that it wasn’t likely to be resolved any time soon:

Hello Mark,

yes, we now find many issue feedback of A9G modules including the on you state, but now we have no enough engineer to support this problem.

i only can try to push if you have big quantity requirement.

Best Regards,

– Overseas Team

深圳市安信可科技有限公司

Shenzhen Anxinke Technology Co., Ltd

I’m posting this as an answer rather than a comment because it directly answers the main question at the top of my original post: “What could be causing HTTPS requests to fail after the first 7 or 8, when HTTP requests work just fine?”. Answer: bad firmware. My best guess is a bug when allocating and de-allocating memory to handle TLS exchanges, but that could be way off.

To anyone else encountering this problem, you have a couple of options:

  • Use WiFi whenever possible.
  • Stick to HTTP requests.
  • Restart the chip after every 7 commands.