Sorry that I still can't replicate your problem, my test log as the picture.
Could you have a try with my test bin file ? if you still have this problem, please offer more information about your test steps or UART1 output logs .
- (168.85 KiB) Downloaded 313 times
Thank you for running the test and looking into this.
the only way you will get to reproduce the bug is when you run MULTIPLE instances of StressTestNetwork.exe at the same time, and you must send a reply from your ESP8266 server to see the issue happening... because it hangs when it tries to process requests and replies...
btw the test firmware is much more stable so whatever your doing is helping keep up the good work
one more request: can you please add support for Multicast to this AT test so I can test it see this post: viewtopic.php?f=16&t=234&p=1098#p1098
so basically when I get to request 10 and I send a reply from my microcontroller it never reaches the client and always return busy... the same thing happens to request 100 and 1000 all return busy no matter what...
can you please check .
I also noticed an issue in the doc see the attached file below:
- doc.PNG (26.66 KiB) Viewed 8769 times
notice that is comes right after the CIPSEND command, so it is missing the \r\n before the 1,CONNECT, but is just appended to the > (> and space after).
Since my code peeks one character after \n to see if it is a '+' or '0' - '4', it is now unable to detect the 1,CONNECT event.
I think it should be \r\n1,CONNECT always.
for example, if i just do a CIPSEND command, and then sent the data. when I read from serial, I should be expecting SEND OK, but connection string can occur.
Also I have experienced only 1,CONNECT is received, and the +IPD is completely lost.
I have wasted so may days trying to figure how to get this to work.
I really think it will be easier if the source code is available. I can probably find the problem in a few hours.
I will create a video demo using the known tools. i'm using V1.0 as well.
I think the main problem is, connection and IPD events messages are getting returned in between AT commands and responses.
For example, if I sent AT+CIPSTATUS
I expect to receive
but instead I get
+IPD,0,316:GET /test HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Accept-Encoding: gzip, deflate
Since I keep reading until I find the string "STATUS", then the entire IPD section is lost.
This is exactly why I think the AT format is more suitable for human interaction, and not for programmability.
Its like you call a function and you get your reply, but together with some other information not related to the function.
Who is online
Users browsing this forum: No registered users and 4 guests
Newbies Start Here
Are you new to ESP8266?
Unsure what to do?
Dunno where to start?
Start right here!
We also have a RTOS version and a MESH version too!
Complete listing of the official ESP8266 related documentation release by ESPRESSIF!
Must read here!