In RTCS after 'some random time amount', send returns 0x1635 RTCS_TCP_CONN_ABORTED

[preetmehta]

Hello,

This is in continuation to 

https://community.nxp.com/thread/497957

I have patched MQX 4.2 with 4.2.0.2 patch.

I have created a TCP server on a project. Now everything works seamless, the connection, disconnection, reconnection, data transfers. But when I keep my system on endurance for continuous sending the data, after a random time the send starts giving -1 and RTCS_geterror returns 0x1635.

More about the system...

I have connected the client on a windows 7 using YAT which is not sending anything. My system is configured to send data out every 200mS. The system keeps sending the data and does not expect any data from outside connection so basically I am not running any recv or select here. This happens in independent thread.

But when I kept my system on endurance, the sending from the system stopped after 10 hrs, 1.5 hrs...x hours...and so on. Now I have loaded the system which sends a chunk of data at every 50mS and send starts returning 0x1635 within 10 to 15 minutes!

I debugged it and got that RTCS_geterror returning 0x1635 after send.

Any help?

Kr,

Preet

[danielchen]

Hi Preet:

Just an information that shutting down a socket will take some time.

You are  sending data every 50ms,  that is a very high frequency for an embedded device,  I guess.

Regards

Daniel

[preetmehta]

Hi Daniel,

Thanks for the reply.

I am not shutting down the socket intentionally from my code, it is happening automatically, which is not what I need.

Is there any settings regarding this?

Moreover can you please let me know, what is the maximum frequency of data MQX RTCS will be able to handle easily?

Kr,

Preet

[danielchen]

Hi Preet:

Yes, you are right.  You do not need to close socket.

You can try to increase the  xx_max parameter to see whether it helps.   Because RTCSPCB represents the pool of Packet Control Blocks - the number of packets you want RTCS to handle at any given time.   of course it will consume more memory.

_RTCSPCB_init = 4;

_RTCSPCB_grow = 2;

_RTCSPCB_max = 20;

_RTCS_msgpool_init = 4;

_RTCS_msgpool_grow = 2;

_RTCS_msgpool_max  = 20;

_RTCS_socket_part_init = 4;

_RTCS_socket_part_grow = 2;

_RTCS_socket_part_max  = 20;

Sorry I don't have the maximum frequency data.

Regards

Daniel

[preetmehta]

Hi Daniel,

Thanks for the information.

//New
_RTCSPCB_init = 4;
_RTCSPCB_grow = 50; //40;//2;
_RTCSPCB_max = 100000; //0; // no upper bound
_RTCS_msgpool_init = 2;
_RTCS_msgpool_grow = 10;//2;
_RTCS_msgpool_max = 100000;//20;
_RTCS_socket_part_init = 4;
_RTCS_socket_part_grow = 2;
_RTCS_socket_part_max = 20;

// Increase the stack size
_RTCSTASK_stacksize = 60720;

this are my parameters set. I increased _RTCSPCB_max to 100000 from 1000, and data when sent at 50mS frequency keep running for almost an hour and a half.

And then again send API starts giving me 0x1635. Have you checked that what I am stating is happening in MQX?

Moreover is there any workaround for this?

Kr,

Preet

[danielchen]

Hi Preet Mehta:

Sorry, there will be no patch for MQX 4.2.  Because MQX v5 is the continuation of classic MQX.

anyway, could you please try to use the attached file to replace your original file to see whether it helps?

 rtcs/source/tcpip/tcp.c

Regards

Daniel

[preetmehta]

Hi Daniel,

Thank you very much for your efforts. I can definitely check with this file with MQX build that I am using.

Moreover, can you please confirm that the scenario that I am facing is a limitation in MQX? So that I get assured that the application that I have made is ok and I narrow down my search in MQX only. This would be a great help.

I understand the limitation of updates on 4.2 as there is 5.0.

Thanking you,

Preet

[preetmehta]

Hi Daniel,

So I had done some endurance testing on my development, which has MQX4.2 with 4.2.0.2, and now I send data at every 200mS with some regullar interval of gap in between after x seconds of 200mS.

I am facing SW reset in this case with call stack of my transmitter thread as follow

consider it as latest stack first, hence it seems that thread is into _msgq_send_internal and call hierarchy is followed...

0x2fc D:\SVN_RM\build\Atollic\lib\Apollo.gcc_arm\debug\psp\libpsp.a(msgq.o)
0x08221160 _msgq_send_internal

0x80 D:\SVN_RM\build\Atollic\lib\Apollo.gcc_arm\debug\psp\libpsp.a(msgq.o)
0x082210e0 _msgq_send_blocked_internal

0x90 D:\SVN_RM\build\Atollic\lib\Apollo.gcc_arm\debug\rtcs\librtcs.a(rtcscmd.o)
0x081e9e24 RTCS_cmd_issue

0x334 D:\SVN_RM\build\Atollic\lib\Apollo.gcc_arm\debug\rtcs\librtcs.a(tcp_send.o)
0x081f421c TCP_Process_send

0x081edeb4 0x160 D:\SVN_RM\build\Atollic\lib\Apollo.gcc_arm\debug\rtcs\librtcs.a(sock_stream.o)

0x94 D:\SVN_RM\build\Atollic\lib\Apollo.gcc_arm\debug\rtcs\librtcs.a(sock.o)

0x081eb6e8 send

0x94 D:\SVN_RM\build\Atollic\lib\Apollo.gcc_arm\debug\rtcs\librtcs.a(sock.o)
0x081eb6e8 send

0x38 D:\SVN_RM\build\Atollic\lib\Apollo.gcc_arm\debug\rtcs\librtcs.a(sock_util.o)
0x081ee728 SOCK_PROTOCOL_exists_in_system

0x081edeb4 0x160 D:\SVN_RM\build\Atollic\lib\Apollo.gcc_arm\debug\rtcs\librtcs.a(sock_stream.o)

0x94 D:\SVN_RM\build\Atollic\lib\Apollo.gcc_arm\debug\rtcs\librtcs.a(sock.o)
0x081eb6e8 send

.................................................................................................................................................

This is the max stack I capture at this point, but seems it is stuck here. Rest of my threads are in idle routine.

Any Ideas?

Kr,

Preet