atproto
atproto copied to clipboard
igrr
Sending data with CIPSENDI into a disconnected context causes reset
On of the issues I've seen with other software is resetting..
So I tried your latest software - I have to say, this already looks better than others I've seen as you can resolve domain names - thats' great.
So I hooked the board to my router - no problem - set it up as a listener on port 4000, no problem and had my Android App start firing commands at it and manually firing stuff back at the APP - for a minute it looked good - the app responded... but if you look at below... that looks remarkably like a reboot to me!! Any ideas?
+CIPDR:4,92 AT+CIPSENDI=4,"1\r\n0x00" OK
+CIPSENDI:4
+CIPDR:4,96
+CIPRECONNECT:4,-11
+CWSTAT:3 ERROR
+CWSTAT:5 ERROR
CIPNOTACCEPT
+CIPDR:4,100 AT+CIPSENDI=0,"1\r\n0x00" OK AT+CIPSENDI=0,"1\r\n0x00" OK AT+CIPSENDI=0,"1\r\n0x00" OK AT+CIPSENDI=0,"1\r\n0x00" OK
+CIPDISCONNECT:4
CIPNOTACCEPT AT+CIPSENDI=0,"1\r\n0x00" +CIPDR:4,104
c_GORSvfJSzbFjSvbn| +IREADY:"atproto","0.1","b59a35d"
+CWSTAT:1
Yepp.. definitely - connected again - saw some commands coming in - I was a bit slow at sending something back - and as you can see the APP has connected again - till all 4 connections used.. and smack in the middle- the little WIFI board has rebooted. Surely it should not do this..
+CIPDISCONNECT:4
+CIPDISCONNECT:4
+CIPDISCONNECT:4
CIPNOTACCEPT
+CIPDR:4,16
+CIPDISCONNECT:4
+CIPDISCONNECT:3
CIPNOTACCEPT
+CIPDR:3,4
+CIPDISCONNECT:3
CIPNOTACCEPT
+CIPDR:3,8 AT+CIPSENDI=3,"1\r\n" c_GORSvfJSzbFjSxbn| +IREADY:"atproto","0.1","b59a35d" AT+CIPSENDI=3,"1\r\n" +CWSTAT:1
+CWSTAT:5
I noticed when connecting to my router... +CWSTAT:1 then +CWSTAT:5 - meaning connected ... for consistency, once connected would it not make sense to add "OK"??
Next morning: On opening the listening server... I see the unit connecting to my phone app....
Note it accepts connect on 0 - accepts input (but that's not what I'm sending... - my phone app is actually sending status requests GO1\r\n Go2 \r\n GO3 \r\n and GO4\r\n repeatedly)
I have no idea what the +CIPDR:0,4 is
Then the WIFI unit is disconnecting but NOT re-using the connection ... hence after connecting 4 times it gives up?
What I am trying to do (and do with the standard AT set) is to poll 4 arduino inputs and send back status info to the phone itself constantly. But I'm not seeing the above responses from the phone at all.
+CIPACCEPT:0,"109.170.132.114"
+CIPDR:0,4
+CIPDISCONNECT:0
+CIPACCEPT:1,"109.170.132.114"
+CIPDR:1,4
+CIPDISCONNECT:1
+CIPACCEPT:2,"109.170.132.114"
+CIPDR:2,4
+CIPDISCONNECT:2
+CIPACCEPT:3,"109.170.132.114"
+CIPDR:3,4
+CIPDISCONNECT:3
+CIPACCEPT:4,"109.170.132.114"
+CIPDR:4,4
+CIPDISCONNECT:4
CIPNOTACCEPT
I think the problem is that you are sending data into a connection that is already closed:
+CIPDISCONNECT:3
CIPNOTACCEPT
+CIPDR:3,8
AT+CIPSENDI=3,"1\r\n"
Here you can not send data to context 3 because is has already been disconnected. The fact that the module crashes indicates that there is a bug (maybe I'm not checking that the connection is closed and go on sending), I'll fix that. But nevertheless there is no point in sending data into a closed connection.
I have no idea what the +CIPDR:0,4 is
Kindly read the command description (search for CIPDR). It's an unsolicited result code that indicates that data is available for reading.
Another bug is that +CIPNOTACCEPT unsolicited result code is sent without a leading +. Will fix that as well.
Regarding the fact that connections are closed in 2 seconds: I'll add a configurable timeout parameter. Created #20 for that.
Regarding connection re-use. You need to send a +CIPCLOSE command to recycle the connection context when you are done with it. The firmware will not do that for you, because you may want to read received data after the connection has been closed. So make sure you send +CIPCLOSE.
AH, it's starting to be clearer... ok - THANK you for the clarification.. I guess it's just that it's so different to the original AT set... now I understand. Yes could you please check that you ARE freeing these up as it was definitely crashing - which really it should never do. Right - I'll test the above out...
Hi thanks for this... But I'm confused.
So here is a situation where I've set up the listener, my phone has sent a command... and the WIFI board is acknowledging I assume 4 characters coming in ... which I then have to read..
BUT as I've not read them tyhe board is issuing a +CIPDISCONNECT:1
You said the board won't disconnect - so that is this?
+CIPLISTEN:6,4000,2048
+CIPACCEPT:0,"109.170.132.114"
+CIPDR:0,4
+CIPDISCONNECT:0
+CIPACCEPT:1,"109.170.132.114"
+CIPDR:1,4
+CIPDISCONNECT:1
I didn't say it won't disconnect, I said it won't recycle the connection context after disconnect. And as I said, I have created a feature request #20 to tune disconnect timeout. Apparently you are not sending the reply within 2 seconds, so disconnect happens. But you still need to close the connection context so it can be reused. There's a CIPCLOSE command for that.
Right - starting to understand... but...
So I've run out of connections - and I send the command AT+CIPCLOSE=0 - which should free up connection 0..
In practice- it crashes..
+CIPDR:4,28
+CIPDISCONNECT:4
CIPNOTACCEPT
+CIPDR:4,32
+CIPDISCONNECT:4 AT+CIPCLOSE=0
ets Jan 8 2013,rst cause:4, boot mode:(3,6)
wdt reset load 0x40100000, len 24112, room 16 tail 0 chksum 0x7c load 0x3ffe8000, len 2692, room 8 tail 12 chksum 0xdc ho 0 tail 12 room 4 load 0x3ffe8a90, len 8728, room 12 tail 12 chksum 0x6a csum 0x6a r +IREADY:"atproto","0.1","b59a35d"
+CWSTAT:1
Incidentally a mechanism employed in a slightly more expensive module - is that once you are in listener mode, communication becomes transparent - ie the WIFI unit at the Arduino (or whatever is at the other end) simply send data back and forth .... until the other end issues +++ and then waits a second before sending any more - at which point the WIFI unit goes back to command mode. This seems to be a lot simpler. As it stands unless I'm reading something wrong, the Arduino has to now look for +CIPDR and the possibility of other messages such as +CIPDISCONNECT or CIPNOTCONNECT which makes life a little harder....
Thanks for setting up the request for timeout adjust - it is almost impossible to manually test incoming data as by the time you get around to entering a response to the modem,,, it's timed out.