RC76 CME Error 923

IoT Modules Legacy HL Series
1

I am receiving a CME Error 923 from a RC7620 modem without a clear indication of any issue:

Tx: AT+COPS?
Rx: +COPS: 0,0,“Optus AU IoT eSim”,2
Rx: OK
Tx: AT+KTCPCFG=1,0,“a valid internet address”,10113
Rx: +KTCPCFG: 1
Rx: OK
Tx: AT+KTCPCNX=1
Rx: OK
Rx: +KCNX_IND: 1,4,1
Rx: +KCNX_IND: 1,1,0
Tx: AT+KTCPSND=1,28
Rx: +CME ERROR: 923

The “+KCNX_IND: 1,1,0” states the socket is connected, however any attempt to send data results in a 923 error (Error due to invalid state of terminate port data mode).

What is the issue here and how can I work around it?

2

didn’t you need to wait for the “+KTCP_IND: 1,1”?

3

Where is this documented? The documentation states:

Notification format:
• For = 0 or 1:
+KCNX_IND: < cnx_cnf >,< status >,< af >

The indicator is supposed to have 3 parts? So can I assume the socket is not connected until “+KCNX_IND=1,1” is received?

4

I guess +KCNX_IND is for IP layer
for TCP layer, you need to wait for +KTCP_IND

5

OK thanks.

Is there a whitepaper or application note describing the correct sequence of AT commands to bring up a TCP connection?

6

In HL78xx AT command guide, there is some example in Appendix section, i think you can regard that part as reference

Of course for the official explanation, you need to refer to the AT command of RC76

7

I’m also seeing CME ERROR: 923 from time to time.

Our RC76xx application loops sending a single UDP packet about once every two minutes.
sometimes after hundreds of successful iterations we suddenly see CME ERROR: 923 in response to our KUDPSND command - we are expecting to see “CONNECT”, after which we would send the data followed by the termination.

Could somebody please explain in more detail what this error number is trying to tell us, because the description is not (to me, at least) meaningful, meaning that all we can do is a brute force module restart, as the error description gives no indication as to what we might be able to do to recover from the error.

I should add that in our application, we set a custom data termination string (we use “$$” as this can never occur in our data stream).

8

if you restart the UDP session, is it able to send UDP data?

9

‘Restart the UDP session’ - what would one do to achieve that?
Just issue another KUDPSND?
Or delete then re configure with UDPCFG?
Or use KCNXDOWn and bring that back up?

This is what I’m trying to find out - what the appropriate error recovery should be. There are so many levels involved, and the error message doesn’t give me any real clues as to what I should do to retry.

Any guidance would be most welcome, and I appreciate your response.

Chris

10

I am thinking if any of the following can be workaround:

  1. Just issue another KUDPSND?
  2. Or delete then re configure with UDPCFG?
  3. Or use KCNXDOWn and bring that back up?
11

My advice is: don’t attempt any ‘smart’ recovery, just tear the whole session down and rebuild it from scratch. Any other strategy will result in frustration and many lost hours. Ignore the documentation, don’t try and guess what any error codes might mean, at the first hint of any deviation from the happy path, bail completely and restart.

In our case we use TCP connections, so this means closing the socket (do not skip this step even if it reports an error every time), deleting the session, issuing another TCPCFG and going through the whole CNX step again. I’m not sure about the UDP stack, but the TCP stack is pretty unstable. Don’t reason with it, just flush the whole thing down the toilet and start again as soon as it starts to wobble.

12

did you contact distributor to report the bug?