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.
You have nowhere near enough evidence to support a claim as big as a "big bug" in RL-TCP.
Hardly. There's no reason to assume that these particular parts of your projects have any relevance to the problem at hand.
what is the problem?
Impossible to say, based on what little evidence you presented.
Is there some incorrect using in my project?
Probably.
Is it a bug of the rl-tcpNet? And it can't running long period of time continuously?
You're jumping to conclusions rather quickly.
The only thing you've actually shown is that something somewhere in your program broke the internal data structures of the heap. That can happen in a lot of ways, but most typically by incorrect handling of free()d memory blocks or overruns of allocated buffers. The probability that the problem is in the TCP library is actually a good deal smaller than that it's in your own code. For starters, the library will have received a good deal more testing than your code did.
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.