client disconnect cause wdt reset

[ESP_Faye]

Hi,

Sorry that I still can't replicate your problem, my test log as the picture.

test-1.jpg (58.07 KiB) Viewed 15694 times

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 .

[jayc75]

Hi,
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

Thanks
Cheers,

[jayc75]

one more thing I've noticed is ESP8266 never servers the request number 10, 100, 1000..
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:

thank you.

[doughboy]

I debugged this some more and I think in my case, the hang is due to the second connection is coming in after a CIPSEND

> 1,CONNECT

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.

Thanks.

[doughboy]

I am still convinced simultaneous connection is not working due to the messages getting all mixed up. I am using latest 1.0 firmware.

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.

[jayc75]

I agree, if I send request too fast like using 1ms between each request the module goes nuts and the AT stops working all together... it no longer responds to AT and all I get is one line...

I will create a video demo using the known tools. i'm using V1.0 as well.

Cheers

[doughboy]

After adding lots of debug prints,
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
STATUS:3
+CIPSTATUS:0,"TCP","192.168.1.16",56204,1

OK

but instead I get
+IPD,0,316:GET /test HTTP/1.1
Host: 192.168.1.11
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cache-Control: max-age=0

STATUS:3
+CIPSTATUS:0,"TCP","192.168.1.16",56205,1

OK

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.

[doughboy]

I think AT firmware can be improved to not send CONNECT/DISCONNECT and IPD messages if an AT command is pending response.

This will fix this issue once and for all.

[doughboy]

ok, after modifying my code to take into account AT command response may contain response not related to the command, my program is now able to handle multiple connections without a problem.

[jayc75]

can you share a bit of code so I can see what you did please... what exactly did you handle?