hello guys,
I tried to do a stress test on the tcp connection on a cerbuino board with ENC28… and after like 700 to a 1000 requests I get the following error…
instead of vs2012 for debugging I’m attaching MFDeploy… by connecting to the board…
LWIP Assertion "sys_timeout: timeout != NULL" failed at line 256 in C:\MicroFrameworkPK_v4_2\DeviceCode\pal\lwip\
Hello again I think I found what’s causing the issue, hopefully this will help you or others track the bug…
this code will cause the Cerbuino to throw the above error and freeze the board at 1200 requests…
const Int32 uSecondsPerSecond = 1000000;
Byte[] buffer = new Byte[1024];
if (clientSocket.Poll(5*uSecondsPerSecond,
SelectMode.SelectRead))
{
if (clientSocket.Available == 0)
return;
Int32 bytesRead = clientSocket.Receive(buffer,
clientSocket.Available, SocketFlags.None);
if (bytesRead == 0) return;
Debug.Print(new String(Encoding.UTF8.GetChars(buffer)));
}
However this causes the board to give up at 6800 served requests…
// Wait for the client request to start to arrive.
Byte[] buffer = new Byte[1024];
if (clientSocket.Poll(-1,
SelectMode.SelectRead))
{
if (clientSocket.Available == 0)
return;
Int32 bytesRead = clientSocket.Receive(buffer,
clientSocket.Available, SocketFlags.None);
if (bytesRead == 0) return;
Debug.Print(new String(Encoding.UTF8.GetChars(buffer)));
}
the difference is when using 5*uSecondsPerSecond and -1 instead…
Some news at least I found a way to make it work …
basically when I Wrap all Debug.Print() call in my own function and assign my function the Debug attribute which basically tells the compiler not to compile it nor its calls, and building the code as a release code, things seems to work … at least I got up to 40000 served requests…
so something in the debugging code that is causing the board to freeze…
I hope this helps…
here is what my Debug function looks like:
[Conditional("DEBUG")]
public static void DebugPrint(string msg)
{
if (Debugger.IsAttached)
Debug.Print(msg);
}
updates:
Got up to 120,000.00 yes 120 thousand served request before the listener stopped, and the good news is this had no effect on the board as it didn’t freeze and my code reloaded the http listener and things were working again…
so the Debug.Print is definitely to blame for the board freezing and the above mentioned error, now I just wonder why…
run MFDeploy and click on “connect” in the menu then tun your program with debug.print in it. This will tell us the problem is related to data getting printed with no host attached.
That’s what I’ve been using MFDeploy… as VS2012 is way too slow and hangs…
the board freezes while using MFDeploy or not and when using MFDeploy it shows the above error in the output of MFDeploy… when using Debug.Print() and yes I do see my messages in MFDeploy and after about a 1000 served requests it freezes throwing the above error…
but when I don’t use Debug.Print() it served over 120000 requests without issues…
one more thing the Debug.Print() does affect the latest Mountaineer Beta Firmware in a way that the board runs faster while attached to MFDeploy VS not attached to MFDeploy… go figure, usually one would think, things would run slower while attached to a debugger but in the case of the Mountaineer 4.3 Beta, it’s the opposite.
Even though Debug.Print freezes the board, can you output the amount of free memory after every request, every couple of requests, and every few thousand of requests? (Each on a separate run). Do it both with and without your Debug.Print statements.
