Here we can all chat about fixing the AT+ command structure and the associated responses.

User avatar
By pvvx
#3215 Send 256 byte –> TCP packet [256 byte]* -> TCP stack tx packet and wait [ACK] -> internet timeout … answer -> TCP stack rx [ACK] -> buffer TCP stack free -> packet transfer OK. User sends next 256 bytes packet… Final transfer rate < 500 bytes/sec and battery discharged…
* the current implementation libs SDK: TCP transfers: Allocated heap memory and set event timer in xx sec for clearing… Does not free memory after successful acknowledgment [ACK] by the other side. Waiting event timer. The result – 'malloc assert!'
http://www.youtube.com/watch?v=srWKOh7IR7U
User avatar
By pvvx
#3216
igrr wrote:Is this documented somewhere, or maybe you have access to the source code? Is there a function that will collect unused memory that we can call?
esp_iot_sdk/examples/IoT_Demo/lwip/app/espconn_tcp.c [158]
... examples/IoT_Demo/lwip/core/memp.c ...
User avatar
By saper_2
#3263 I got question, after reading data from server-mode I need to call CIPCLOSE=connection-context-id ? Because if I do this it kill's esp ( wdt_reset...).
What I'm doing:
Code: Select all+IREADY:"atproto","0.1","b59a35d"

+CWSTAT:1

+CWSTAT:5
AT+CIPLISTEN="TCP",2222

+CIPLISTEN:6,2222,2048

+CIPACCEPT:0,"192.168.2.26"

+CIPDR:0,17

+CIPDISCONNECT:0
AT+CIPRD=0

+CIPRD:0,17

Test some data  !

OK
AT+CIPCLOSE=0

OK

Now I send again data to esp and after about 2sec:
Code: Select all 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
rl
+IREADY:"atproto","0.1","b59a35d"

+CWSTAT:1

+CWSTAT:5


Similar, If I do not call CIPCLOSE then connection-context-id goes to 4 and stay on 4, I get CIPNOTACCEPT but data is put in buffer anyway and eventually glued together (if not read):
Code: Select all+IREADY:"atproto","0.1","b59a35d"

+CWSTAT:1

+CWSTAT:5
AT+CIPLISTEN="TCP",2222

+CIPLISTEN:6,2222,2048

Sending "Test data ! !"
Code: Select all+CIPACCEPT:0,"192.168.2.26"

+CIPDR:0,13

+CIPDISCONNECT:0
AT+CIPRD=0

+CIPRD:0,13

Test data ! !

OK

Sending "Test data ONE ! !"
Code: Select all+CIPACCEPT:1,"192.168.2.26"

+CIPDR:1,17

+CIPDISCONNECT:1
AT+CIPRD=1

+CIPRD:1,17

Test data ONE ! !

OK

Sending "Test data TWO ! !"
Code: Select all+CIPACCEPT:2,"192.168.2.26"

+CIPDR:2,17

+CIPDISCONNECT:2
AT+CIPRD=2

+CIPRD:2,17

Test data TWO ! !

OK

Sending "Test data THREE ! !"
Code: Select all+CIPACCEPT:3,"192.168.2.26"

+CIPDR:3,19

+CIPDISCONNECT:3

Sending "Test data FOUR ! !"
Code: Select all+CIPACCEPT:4,"192.168.2.26"

+CIPDR:4,18

+CIPDISCONNECT:4
AT+CIPRD=3

+CIPRD:3,19

Test data THREE ! !

OK
AT+CIPRD=4

+CIPRD:4,18

Test data FOUR ! !

OK

Sending "Test data FIVE ! !" and "Test data SIX SIX SIX ! !"
Code: Select allCIPNOTACCEPT

+CIPDR:4,20

+CIPDISCONNECT:4

CIPNOTACCEPT

+CIPDR:4,45

+CIPDISCONNECT:4
AT+CIPRD=4

+CIPRD:4,45

Test data FIVE 5 ! !Test data SIX SIX SIX ! !

OK

Calling now CIPCLOSE=4 to release connection context handle (and buffer) and next sending data to esp:
Code: Select allAT+CIPCLOSE=4

OK

 ets Jan  8 2013,rst cause:4, boot mode:(3,7)

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
rl
+IREADY:"atproto","0.1","b59a35d"

+CWSTAT:1

+CWSTAT:5

Ends with wdt_reset :/ - I suppose this is a bug?