PUT/POST and callback - Arduino code hangs

[mhanuel26]

Hello Team,

I found a behavior that I want to expose here in order to someone tell me if it's a bug, for me it's certainly something critical since arduino code hangs.

I was making a PUT request to arduino when I notice the code hangs, the code also hangs with a POST request, my setup is the BasicWiFiServer example, just run it and issue a POST request using curl, for example

Suppose winc is at 192.168.1.60

curl -v --data "myname=manuel" http://192.168.1.60/my_form

Arduino console will print something like this

(APP)(INFO)Chip ID 1503a0
(APP)(INFO)Firmware ver : 19.4.4
(APP)(INFO)Min driver ver : 19.3.0
(APP)(INFO)Curr driver ver: 19.3.0
Attempting to connect to SSID: MOOI
SSID: MOOI
IP Address: 192.168.1.60
signal strength (RSSI): 4294967270 dBm
SOCKET_MSG_BIND CALLBACK CALL
SOCKET_MSG_BIND CALLBACK end CALL
SOCKET_MSG_ACCEPT CALLBACK CALL
SOCKET_MSG_ACCEPT CALLBACK end CALL
new client
SOCKET_MSG_RECV CALLBACK CALL
SOCKET_MSG_RECV CALLBACK end CALL
POST /my_form HTTP/1.1
User-Agent: curl/7.38.0
Host: 192.168.1.60
Accept: /
Content-Length: 13
Content-Type: application/x-www-form-urlencoded

The SOCKET_MSG_BIND CALLBACK CALL and similar are debug prints I added, if you go to source file you cann in the callback function for socket the prints, I added at the start and end of switch cases, but also I added a case for the send call back like this

    case SOCKET_MSG_SEND:
        send_ret = *(int16_t*)pvMsg;
        Serial.print("sent ");
        Serial.print(send_ret);
        Serial.print("bytes ");

just define before switch clause the send_ret variable
int16_t send_ret;

Ok, now what's the bug?, well the MCU have just hangs, bad for an embedded, actually since I got deeper on this for a f.. day, I know that the winc1500 stack fails after several calls to client.write, just to realize that if you don't call the receive for all the characters on winc1500 subsequent calls to it will stop winc1500 from getting you a dma address to write the outgoing message, for example, the function hif_send in m2m_hif.c will fails to fill the variable dma_addr which under normal circumstances it's a 32 bit address but when it fails the command just go thru but the variable stay at 0, causing a "Failed to alloc rx size" if you place asf stack to be verbose.

I found that receiving all the incoming buffer before continuing with client.prints just solve the issue, in my previous example, the content-length is 13 so you need to extract 13 chars before continuing, just put this on th code

              for(int k=0; k<13; k++){
                  c = client.read();
                  Serial.print(c);
              }

Then you will see this output on Arduino Console

(APP)(INFO)Chip ID 1503a0
(APP)(INFO)Firmware ver : 19.4.4
(APP)(INFO)Min driver ver : 19.3.0
(APP)(INFO)Curr driver ver: 19.3.0
Attempting to connect to SSID: MOOI
SSID: MOOI
IP Address: 192.168.1.60
signal strength (RSSI): 4294967269 dBm
SOCKET_MSG_BIND CALLBACK CALL
SOCKET_MSG_BIND CALLBACK end CALL
alive
alive
SOCKET_MSG_ACCEPT CALLBACK CALL
SOCKET_MSG_ACCEPT CALLBACK end CALL
new client
SOCKET_MSG_RECV CALLBACK CALL
SOCKET_MSG_RECV CALLBACK end CALL
POST /my_form HTTP/1.1
User-Agent: curl/7.38.0
Host: 192.168.1.60
Accept: /
Content-Length: 13
Content-Type: application/x-www-form-urlencoded

myname=manuel
sent 15 bytes
sent 1 bytes
sent 1 bytes
sent 23 bytes
sent 1 bytes
sent 1 bytes
sent 17 bytes
sent 1 bytes
sent 1 bytes

more sent x bytes here...

Could someone just tell me if there is something we can do to avoid a hard crash like this in case the application layer fails or miss to extract some received data?

Cheers,

[sandeepmistry]

Hi @mhanuel26,

Thank you for reporting this issue. I've been able to reproduce with a MKR1000 and the WiFiWebServer example (I could not find the "BasicWiFiServer" example you mentioned).

Could someone just tell me if there is something we can do to avoid a hard crash like this in case the application layer fails or miss to extract some received data?

As far as I know, this is a limitation of the current WINC1500 buffering architecture, there's a similar report in #32. So, the workaround you mentioned to read available data is the only suggestion I have now.

To move forward with the issue, I would recommend you Open a Support Case with Atmel. If you decide to do this, please share your case number here.

[mhanuel26]

Hi sandeepmistry,

Sorry it was a type, that is the sketch I used also for the tests.

Well, It's bad that we need to wait for Atmel to fix it!

Thanks for letting me know!

[sandeepmistry]

Hi @mhanuel26,

I've submitted #77 to try to resolve this. If you get a chance please try it, you can download it from the following link and replace <sketch book>/libraries/WiFi101 with it.

https://github.com/sandeepmistry/WiFi101/archive/socket-buffer.zip

[sandeepmistry]

I believe this is fixed by the changes in PR #204 which has been merged. Please try out the master version of this library and let us no if the issue still occurs.