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.
This is actually interesting. If you can write a tiny test program that does not explicitly allocate any heap memory and uses static data only and can cause this to happen, you will have good reasons to report this to Keil as a candidate bug.
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.