RTK exceptions when using TCP sockets

I’m using OAT 3.02 ADL, Remote Mode
I get a lot of RTK exceptions that reset the module when I use TCP sockets. These exceptions has occurred when:

  1. Passing messages to the TCP stack with the ed_SendDataExt function and having these messages accumulate by the stack because of bad network state.

  2. When 5 or more TCP open sockets get closed by the remote peer at the same time.

This is part of the trace that shows the exception. I boldfaced some messages that I comment after the trace:

16497.303 Trace IP 1 TCP, TcpReadyToSend, MaxLen: 436
16497.395 Trace IP 6 [TCP allow Tx] Too much frame
16497.507 Trace IP 6 [TCP allow Tx] Too much frame
16497.550 Trace IP 9 SendData 2 : 0
16497.562 Trace IP 1 TCP, TcpReadyToSend, MaxLen: 386
16497.618 Trace IP 6 [TCP Manage] Timeout : Retransmit frame 1
16497.624 Trace IP 6 [TCP allow Tx] Try to Retransmit a frame
16497.627 Trace IP 6 [TCP allow Tx] Send retransmit frame
16497.629 Trace IP 6 [TCP allow Tx] Too much frame
16497.674 Trace IP 1 [ed_DialupGetGeneralInformations]
16497.730 Trace IP 6 [TCP allow Tx] Too much frame
16497.839 Trace RTK 1 Except RTK …152 1022e94 18
16497.839 Trace RTK 3 ##Stack

16497.839 Trace RTK 3 Unable to find the string of the remote trace in the file (ID = 5603)
16497.839 Trace RTK 3 Unable to find the string of the remote trace in the file (ID = 5604)
16497.839 Trace RTK 3 Unable to find the string of the remote trace in the file (ID = 5605)
16497.839 Trace RTK 3 Unable to find the string of the remote trace in the file (ID = 5605)
16497.839 Trace RTK 3 Unable to find the string of the remote trace in the file (ID = 5605)
16497.839 Trace RTK 3 Unable to find the string of the remote trace in the file (ID = 5605)
16497.839 Trace RTK 3 Unable to find the string of the remote trace in the file (ID = 5605)
16497.841 Trace IP 6 [TCP allow Tx] Too much frame
16497.953 Trace IP 6 [TCP allow Tx] Too much frame
16498.063 Trace IP 6 [TCP allow Tx] Too much frame
16498.175 Trace IP 6 [TCP allow Tx] Too much frame
16498.286 Trace IP 6 [TCP allow Tx] Too much frame
16498.397 Trace IP 6 [TCP allow Tx] Too much frame
16498.509 Trace IP 6 [TCP allow Tx] Too much frame
16498.620 Trace IP 6 [TCP allow Tx] Too much frame
16498.731 Trace IP 6 [TCP allow Tx] Too much frame
16498.843 Trace IP 6 [TCP allow Tx] Too much frame
16498.954 Trace IP 6 [TCP allow Tx] Too much frame
16499.064 Trace IP 6 [TCP allow Tx] Too much frame
16499.176 Trace IP 6 [TCP allow Tx] Too much frame
16499.287 Trace IP 6 [TCP allow Tx] Too much frame
16499.398 Trace IP 6 [TCP allow Tx] Too much frame
16499.510 Trace IP 6 [TCP allow Tx] Too much frame
16499.621 Trace IP 6 [TCP allow Tx] Too much frame
16499.732 Trace IP 6 [TCP Manage] Timeout : Retransmit frame 2
16499.739 Trace IP 6 [TCP allow Tx] Try to Retransmit a frame
16499.745 Trace IP 6 [TCP allow Tx] there is already 2 frames, not able to do retransmit
16499.750 Trace IP 6 [TCP allow Tx] Try to Retransmit a frame
16499.755 Trace IP 6 [TCP allow Tx] there is already 2 frames, not able to do retransmit

The first two messages show how the MaxLen parameter has diminished indicating that messages sent by me are being accumulated by the stack.
The next shows the exception. The module is reset but the traces keep on running.
And then I boldfaced a message that is always present sometimes before, sometimes after the exception and it is displayed almost every 100 ms. I think this is causing the exception.

Any ideas ?

Note: Do you think this just a Remote Mode issue ?

Hi,
I think that the problem is because of low signal strength and not because of limiation of Remote mode. This is because, as the received signal strength of your module is quite low, the lower layers are not able to send the data to the GPRS network. So these layers buffer the data until the signal stength become high, so that they might send that data. But your Open-AT application keep on sending data (by calling ed_SendDataExt () API). This might overflow the internal buffers of the lower layers (stack layers) and hence, lead to RTK exception.
:slight_smile:

Hi,

I hope that this is not the case, assuming that ed_SendDataExt () is not called if the data request call back function wasn’t called to inform the application that it might send data, and not more than maxlen is transmitted. Otherwise I would say this is a bug in the stack! Since I have no control over buffer sizes and usage of the lower levels, the API needs to tell me how much is allowed that no buffer overrun in the next level down occurs. And the next level down must do the same with the level which is 2 down…

However, I’ve seen similar traces myself. And a workaround helped: In the data request callback function remember maxlen, then start a timer with very short period, and then in the timer call back function use ed_SendDataExt (). That worked! But I don’t like it, since it’s not supposed to be that way. I think this is a pretty bad hack and it really looks like it is a bug… It might help in your case, juanc, too.

Probably it’s only a remote mode issue, but in the target application I had unexplained crashes which happened when I was transmitting data… Not sure if they were due to this problem.

Best Regards,
Jan