AT client lib: processResponse race condition?

[arnoutdekimo]

Hi,

I am debugging a new issue, that seems to be timing related. It's pretty trivial to analyze though.

Situation:

• We are requesting from a socket:

0:01:06:964 - +USORD: 0,245 0:01:06:965 - OK 0:01:06:965 - AT+USORD=0,1024 0:01:07:001 - 10 }}}}" 0:01:07:007 - 0:01:07:007 - OK 0:01:07:007 - 0:01:07:007 - +UUSOCL: 0 0:01:07:008 - OK 0:01:07:008 - Server: BaseHTTP/0.6 Python/3.5.2 0:01:07:009 - Date: Fri, 24 Nov 2023 12:16:07 GMT 0:01:07:010 - 0:01:07:011 - {"nonper" : {"OTA": {"crc": 1062505965, "size": 217224, "ver": "aaaa Built aaa", "url":"/getOTA.html"}, "per" : { "senscfg" : { "acc_hwt_sens" : 10 }}}}" 0:01:07:016 - 0:01:07:016 - OK 0:01:07:016 - 0:01:07:016 - +UUSOCL: 0

• We are here in code:

Issue:

If we "slow down the code", causing the entire reply to already be inside of the response buffer, I think what happens is that the code in processResponse first sees that there is an OK at the end (stoptag), instead of first checking whether the URC was actually matched, and an OK followed it.

The result is that sometimes the parser will miss replies.

Am I correct in this assumption?

[arnoutdekimo]

EDIT - the bufferMatch should check only at the START of the buffer. So that shouldn't be the issue. Ok, give me a few mins, I'll narrow it down

[arnoutdekimo]

So, this is just an issue.. because of debugging. The details get complicated, but simply said, if I single step over lines in uCellSockRead, like here:

It is -normal- that when it tries to retrieve thisActualReceiveSize, it fails.

Why? Because, when you single step, the debugger breaks the entire MCU, including the UART peripheral. Since the modem cannot send everything fast enough before the debugger breaks, data is lost.

I initially tried to increase DMA buffer sizes, but all of that does not matter when the UART peripheral (and DMA) are suspended during debugging.

The only correct way to debug this code, is to let it run until the modem has sent all data out, so practically this means placing breakpoints after the full command read loop. e.g here:

When the debugger breaks there, the underlying code must have (in loop) let the UART do its thing to fill up the buffers without interruption, and retrieve it.

So yea, never mind this issue ..

[RobMeades]

Hehe, love the GIF.

It is true, of course, that in real time systems one needs a "stream" type log of activity which, for some reason, no [embedded!] platform's toolset ever really gives you. So we do printf()'s, or our own RAM-log type buffered systems, as required (internally for our cellular modem development we have a very complex tool that does tokenised "prints" for real time modem operation).

Anyway, sorry you had to be distracted by this and thanks for posting a resolution.