MQX Locking in the TCPIP_task()?

[Tim562]

Hi All,

     I'm seeing situations in my project where the MQX/RTCS Task "TCPIP_task()" never blocks to allow other tasks to run. Since it's at priority level 6 that means it's pretty much the only thing still running. This happens pretty regularly when I have multiple socket connections established (some as server from a listen/accept socket, some as a client from a connect call) and the devices are transferring config messages between them upon new connection (aprox a dozen msgs from 1K to 100K in size). I can seemingly prevent this from happening if I put a little space between message requests (about 30mS seems to work great) but that's not a solution to the problem. When in this mode, I can pull the Ethernet cable (to prevent further communications) and the problem doesn't resolve itself. If I force the socket to close, the problem clears itself and normal operation resumes. From what I see, TCPIP_task() runs an endless while(1) loop where it calls RTCS_msgq_receive() and keeps track of timing. since RTCS_msgq_receive() is really the only function call in the TCPIP_task() while(1) loop, I'm guessing that it should block occasionally to allow other tasks (my project code for example : ) to run?

     Any ideas what I might look at to determine what is keeping RTCS_msgq_receive() so busy? Otherwise the networking seems to be working properly. My client is acting as both a TCP client (making outgoing connect() calls) and a server using listen() / accept() calls, and also as a web server. When locked in the RTCS_msgq_receive() task, the web server seems to continue working properly. Also, when in this mode, I can pull the Ethernet cable (to prevent further communications) and the problem doesn't resolve itself. If I force the socket to close, the problem clears itself and normal operation resumes.

     I'm using RTCS 4.0.2 ported into MQX 3.8.1.1 on a Freescale MPC-5125 processor (with CodeWarrior for MobileGT 9.2). Thanks for any suggestions!

Best,

Tim

[Tim562 · Accepted solution]

Hi all,

     It appears that I have stopped MQX from locking in the "TCPIP_task()". I did it by increasing the priority level of my project tasks that service the socket recv() function calls. Whenever my project creates a socket I create a "Receive Task" to handle the blocking calls to the recv() function. I had set the priority level for these tasks relatively low at 11 (same as main tasks). The idea being that TCP flow control would kick in to prevent data loss and my project would be less likely to be overburdened with excessive incoming data. As soon as I set the priority for my recv() tasks to 9 (same as the transmit tasks), all lockups stopped.

     It appears that if the MQX recv() function isn't serviced often enough the MQX/RTCS system task "TCPIP_task()" (set at priority 6) can get into a state that prevents it from ever blocking to allow other tasks to run (including my project recv() tasks). Once this happens, even removing the Ethernet connection will not restore operation. The socket has to be forced closed before things will work again.

     I am aware that RTCS 4.0.2 ported into MQX 3.8.1.1 is not the latest and greatest from MQX but has anyone else run into this? Is this perhaps a problem with RTCS that has been corrected in later releases? I would sure be interested in patching my 4.0.2 version to the latest if it would help?

     Hope this helps anyone else facing a similar issue.

Best Regards,

Tim

[Tim562]

A little further info,

     It appears that getting stuck in the MQX/RTCS Task "TCPIP_task()" is preceded by my call to send() with a 27,057 byte message. When I get stuck, the send() function never returns. Shortly before this call to send() that never returned, I had sent four other messages. One of those messages was also exactly 27,057 bytes long and sent without a problem. I caught this event with just two devices talking to each other. The socket of the device I had under debug was created by a listen socket as follows: (socket(), bind(), listen(), accept(), use new socket returned by accept() for transmit / receive ).

~Tim