URC bundled with other data - split after lock release?

[arnoutdekimo]

Hi,

Perhaps more of a question:

I am fetching data through a socket, and when the last piece of data comes in, the module reports the socket being closed immeidately afterwards:

Note how there is +- no delay between the URC and the last piece of data

A question - If the data is pushed into the code's ringbuffers (as a big block from DMA), and then triggers and event uPortEventQueueSendIrq => That causes urcCallback to be called, and attempting to check if there is an URC in.

BUT, the lock is then taken by the uSocketRead call, which wants to consume the data.

It will only consume the right amount of data (indicated in the +USORD: 0,988,"[c0]?[b, .... number), BUT

Now the real question:

• Does ubxlib, when the lock is released, again check whether there was remaining data in the buffer, and parse any remaining URC's that were in there (but were not yet parsed due to this lock)
• (my fear is that the URC parsing only happens, on a trigger base from incoming data perhaps. But if that trigger bundles data, and is .. blocked because of the lock, can we then miss URC data?)

Hopefully this is a much easier question for you, than for me to figure out..

Thank you for the help!

[RobMeades]

In the case of a socket read we are in uCellSockRead(). There are bytes pending and we will have sent AT+USORD=blah around here:

...then we read the response, the bit between the quotes, and wait for the \r\nOKr\n at the end with uAtClientResponseStop().

At the end of this the AT Client is unlocked. In uAtClientUnlock() there is this bit of code:

...which checks if there is still stuff left in the AT Client buffer to process (in this case the \r\n+UUSOCL: 0\r\n) and, if there is, it sends the "there is UART data" event again so the stuff should get processed at that point.

That's the theory: not to say there isn't a bug of course, but that's how it is meant to work.

[arnoutdekimo]

That's the perfect reply. Thanks! Super clear.

I'm still struggling with something in the socket that's going wrong, but I'll debug it further and make a more relevant post if it turns out to be an issue on the ubxlib side. I've finally got thread-aware debugging working on my stm, so hopefully that'll speed tings up

Thanks again!

[RobMeades]

Very nice! Always found getting the STM32Cube tools to play ball a bit of an uphill battle, but once there it is likely worth the effort.

[arnoutdekimo]

Ok, major issue fixed on my end, causing very rare corruptions in UART data in the port folder of the lib.. That's gonna explain quite a few of those weird things (side from the issues due to the PWRON glitch thing). Fingers crossed, but I think this was a big one, and I see blue skies coming! Anyway many thanks for all the support!

[RobMeades]

Very well done on finding it! Intermittent streamed-data-oriented things are awful to track down.

Blue skies on a crisp autumn morning are very welcome but, should the drizzle from a grey sky come back, don't be afraid to post an issue; at a minimum we can give you an alternative view of the problem.