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.
I have the same problem in the past - and it was my problem... I fill a buffer more than its size...
Thanks for all your replys.
I take your advice,and i test the tcpNet in a very tiny project,then turns out everything is OK.
I have not enough evidences to say that there is a big bug. i'm jumping to the conclusions rather quickly. Just because the problem almost put me mad.I'm sorry. I take back my words.
Now, i think there must be something wrong in other parts of my project,such as BSP part. I think i will resolve it finally, although the problem still unresolved.
Thanks Happy new year!
Most common issues are buffer overflows or timing issues related to allocation/deallocation of memory.