Hi Tuna,
This PR fixes the second problem.
- Update the code to drop and warn unknown message after receiving success or error token.
The first problem mentioned in this thread is a feature request. It will be updated in another PR.
I would like to take the chance to explain this PR and undefined message type. The logic to decide AT response type is _getMsgType function.
AT response will be considered as AT_UNDEFINED only when
- It doesn’t have prefix
A input line with prefix won’t be regarded as AT_UNDEFINED message.
+<prefix>:<payload>
-
It is not declared in URC without prefix table
urcTokenWoPrefix is the logic to check URC without prefix. -
It is not expected in the AT command response
_processIntermediateResponse is the logic that checks the expected input line for the current AT command.
The default behavior for cellular interface when receiving a AT_UNDEFINED message is to drop this message and clear receive context.
Cellular module porting can also use its own handler for AT_UNDEFINED message with the _Cellular_RegisterUndefinedRespCallback API. If the undefined response handler returns CELLULAR_PKT_STATUS_OK, cellular interface will keep processing without clearing receive context.
For the problem mentioned in this thread, I describe the change in comment.
> AT+CFUN=1
<
< OK // The success token is received. The AT command type is cleared in receive thread. The following line won't be appended to response.
<
< ^SYSSTART // This command will be regarded as AT_UNDEFINED. It can be handled by undefined response handler if registered.
The atCmdType is now cleared in pktio thread. The pktRequestMutex ensures that only one command can be sent to cellular modem at a time. So we don’t have to worry about the response of next AT command. If current AT command times out, there may be a problem with the cellular modem. In this case, it is recommended to reset the cellular modem.