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 ofHTTPPOST
– 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:
- AT command reference for the A6 and A7, which are similar-but-not-identical chips made by the same manufacturer.
- A Hackster.io project that mentions several of the AT commands
- Code examples from the chip manufacturer, which are poorly formatted but easier to read if you view the page source.
- ESP8266 + A9G combo GitHub project, which includes some background info.
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.