After further testing i determined the problem isnt just restricted to external power, it also happens while debugging from the IDE. And as i added to the original post it is not just restricted to the startup either, it seems to happen at random when the server gets a request.
Either way I tried your idea and connected a 420uF capacitor (actuallly one 220 and two 100 in parrallel) between Vin and ground. At first i thought it had remedied the problem because the server was responding well to requests, but after a couple of minutes of sending GET request with the Postman chrome extension the same thing happened and the DigiX buckled under. I retried a couple of times but with no great success, every time it was just a matter of time before the program would lock up. So too much current draw alone might not be enough to explain it... it is also strange to me that it only happens sometimes instead of all the time, and also that it had not happened a single time in the first month or so while i was playing with the DigiX in server mode. Can we completely rule out that the unit has become defective?
Anywho i did further debugging and i found out the server would finish sending the reply every time, and only locks up when the next GET request is recieved. When this happened the program would not get past the wifi.serverRequest() function.
I also noticed another perculiar thing, which was errors in the path returned by wifi.serverrequestpath() such that when sending a request like this from the postman extension:
/?dose_Mg=2&user=xxx&password=xxx&dose_Ca=5&dose_kH=21&command=setDosing
It would sometimes (and only sometimes) be recieved incorrectly, for example like this:
/?dose_Mg=2&user=xxx&password=xxx&dose_Ca=5&dose_keWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Safari/537.36
At first it appeared to me that the first part of the request was correct but then turned into gibberish, but upon closer inspection it seems like the HTML header has been included in the request path by accident. Each time the error happens a new part of the header is included in the requestpath.
Next i found the "EthernetCompatible" Webserver example that is included for the DigiX. Here the entire request including header is printed over serial connection. I again tried to bombard the DigiX with requests to test if i could replicate the same error again (i was hopeful, because this example doesnt include the wifi.serverRequest() function which appeared to give me problems before) and i was not able to make the program crash so far.... even after many more tries, although i will keep stress testing it over the coming days to make sure it is not too good to be true. I also noticed that the request path seemed to be correct every time while testing, something which had not been the case for the code posted in my original post.
I then started digging a little into the DigiFi library to identify problem which allowed the program to hang. I noticed that both ready() and serverRequest() make calls to readResponse() which seems to be the only place the program can get stuck (it contains a while loop). In the library readResponse reads as follows:
String DigiFi::readResponse(int contentLength) //0 = cmd, 1 = header, 2=body
{
String stringBuffer;
char inByte;
int rCount = 0;
int nCount = 0;
int curLength = 0;
bool end = false;
Serial1.flush();
while (!end)
{
//look for this to be four bytes in a row
if (Serial1.available())
{
inByte = Serial1.read();
curLength++;
debugWrite(inByte);
if(contentLength == 0){
if (inByte == '\n' && rCount == 2 && nCount == 1)
{
end = true;
int strLength = stringBuffer.length()-3;
stringBuffer = stringBuffer.substring(0,strLength);
}
else if (inByte == '\r')
rCount++;
else if (inByte == '\n')
nCount++;
else{
rCount = 0;
nCount = 0;
}
}
else if(curLength>=contentLength)
end = true;
stringBuffer += inByte;
}
}
Could it be that somehow a mishap happens in this function that prevents "end" from being set as true and thus continues the loop forever?
If so, could it be and idea to add some kind of timeout to the readResponse function so that if something goes wrong, then the whole program doesnt hang?
I will dig a little more when i get time... I dont fully understand the problem yet i think
