This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

I might find a big bug of rl-tcpNet

Hi,

I write a Modbus_tcp Slave project using the tcpNet, i think it is very simply. Just receive a request command of modbus_tcp, and then send a reply command. But the project running 1 or 2 days continuously, the communication is broken, and can't connect the tcp again.

Follow are main parts of my project

...
modbus_callback(...)
{
     ...
     case TCP_EVT_DATA:
         // read the received command data
         recFlag = 1;
         break;
     ...
}
...
main(){
    ...
    sock = tcp_get_socket(TCP_TYPE_CLIENT,0,60,modbus_callback);
    tcp_listen(sock,502);              //get a client tcp socket
    while(1){
        main_TcpNet();
        if(recFlag==1){               //if received a request command of modbus,
            buf = tcp_get_buf(...)    //then reply a data command
            ...
            tcp_send(...)
            recFlag = 0;
        }
    }
}

Then i used the debug library of the rl_tcpNet (TCPD_ARM_L.lib),and want to find the problem.
Follow are the output of the debug library when the TCP communication break.

MEM: Releasing 72 bytes
MEM: Used 80 bytes in 2 blocks
MEM: Releasing 80 bytes
MEM: Used 0 bytes in 1 blocks

ETH: *** Processing Ethernet frame ***
ETH: Dest.MAC: FF:FF:FF:FF:FF:FF
ETH: Src. MAC: 00:19:B9:88:7F:41
ETH: Frame len: 253 bytes
ETH: Protocol : 0800
MEM: Releasing 268 bytes
MEM: Allocated 1 blocks from IRQ
MEM: Used 4294967120 bytes in 0 blocks

what is the problem? Is there some incorrect using in my project?
Is it a bug of the rl-tcpNet? And it can't running long period of time continuously?

if you want to see the more code or the whole project i can send a e-mail to you.

Parents Reply Children
  • That's quite a big if, isn't it?

    All we've seen is a very small snippet of the tiny test program.

    I'm no great fan of the TcpNet library (or Keil's prohibitively expensive source distribution policy). I use it because I have put a lot of work put into making it usable for our requirements; however, it does appear to be stable for 'simple' TCP/IP connections. We've had TCP sessions continuously running for weeks on end with no detected problems.

    I suggest that the OP gathers more evidence.