[Bug] Improper handling of unsolicited and solicited codes of the same command

[tpecar-ltek]

While porting FreeRTOS-Cellular library to SIMCom SIM800C, I've noticed that the cellular_pktio.c : _getMsgType() doesn't discern between a solicited response (that we're currently sending / waiting on) and unsolicited response of the same command.

Currently (at commit dda105fbd) the unsolicited response will be detected as solicited, thereby invoking the wrong callback.

---

In my case this happens with AT+CREG? when

• the module is configured to emit URCs with AT+CREG=2 (Cellular_ModuleEnableUrc(), this was brought over from sim70x0 module support)
• the module is disconnected with AT+CFUN=4, within Cellular_RfOff()
• the module is connected with AT+CFUN=1, within Cellular_RfOn()
• the registration status is manually probed with AT+CREG?, within Cellular_CommonGetServiceStatus() -> atcmdQueryRegStatus(), the command waits for response with prefix +CREG

In this scenario, the modem first responds with +CREG: 2 URC, for which _getMsgType() erronously returns AT_SOLICITED and thus the wrong parser is called.

---

While the most obvious workaround would be to simply disable URC for this command and rely on manual probing (which the library already seems to do, at least for network registration status), it would be beneficial if we are able to handle such situations.

[chinglee-iot]

@tpecar-ltek I will take a look at this problem and reply soon.

[chinglee-iot]

@tpecar-ltek Thank you for your feedback. We update this problem in the commit #90. The problem you described happens when solicited response and unsolicited response has the same prefix. Cellular modem will regard them all as solicited response. In that case, AT command response callback must be able to handle the URC received and call the URC handler if required.

[chinglee-iot]

I will close issue first. If you have any question, please open this issue and comment.

[tpecar-ltek]

I have encountered the same issue with data commands on SIM800C.

When you configure the TCP/IP stack for manual mode (via command AT+CIPRXGET=1, multiplexed mode AT+CIPMUX=1), the stack will report back with +CIPRXGET:1,<socket id> for new data

However, invoking read at the same time (as is done within the tcp_sockets_wrapper) via AT+CIPRXGET=2,<socket id>,<requested length> will erronously parse the URC as command response

and the actual response AT+CIPRXGET=2,<socket id>,<requested length>,<retrieved length> isn't parsed.

---

The current solution only fixes the CREG/CEREG/CGREG commands.