I have a strange behaviour with my G120.
I’m running a quite heavy app with multiple threads, timers, writing to SD card TCP Connections and a lot of data shuffling from ethrnet to memory to ethernet.
Currently the app is not close to the 32 TCP connections limit. I think I have abou 10 or 15 Connections open at a time.
When it’s running for a while with attached Debugger it suddenly does not respond to any TCP Messages anymore. I think it does not execute anything at this Point.
When I then press Pause and Run in Visual Studio it continues working.
Haven’t tested too much without Debugger so far, so I can not say if it would also freeze without Debugger or not.
What I also have seen is that not all Debug.Print’s Show up in the Visual Studio Output window.
Does anyone have a similar behaviour?
Is this a Debugger only Problem?
For this Project the device must run more or less 24/7.
My configuration:
G120 HDR 1.1
GHI ENC28 1.1
GHI SD Card 1.4
GHI USB Client DP 1.3 (supplied with a 1.5 Amps power supply at 7.5 Volts)
GHI Char Display V1.0
FW 2.4.11.0 (NETMF and Gadgeteer Package 2013 R2)
Visual Studio Pro 2012 U3
Win 8.0 Pro
WinUSB Drivers (at least I hope so)
Thank you, these limits I have not been aware of so far.
I don’t think that the file Limit is the Problem, because normally I should have only 2 files open at a time: The log file for writing and one out of many other files which are read and writting in the main process.
The number of listening socket might become a Problem in the future but I don’t think that this is the current problem.
If one operation cycle works, than the following should work too because it will never need more resources than the 1st one.
Only if open sockets ‘get lost’ somehow this may be a problem. I’ll check that.
But finally this does not explain why it starts working after i Pause/Run the Debugger in Visual Studio.
Which Timing do you think of?
The debugger or my program?
Currently I let it run without Debugger.
I can not remember seeing it working for such a Long time, where long is about one hour.
So may be it’s really a Debugger Problem, or USB. Sometimes my Laptop can’t start an internal USB hub on Startup, may be it has more USB Problems than I know of.
It’s an USB 3.0 port, which made Problems with the GHI Drivers in the beginning I think.
Unfortuenatelly I don’t have any 2.0 ports on my Laptop.
I don’t think so.
I have multiple Independent threads running or waiting for data from Network.
A FTP Server (an enhanced Version of the NETMF FTP)
Two TCP Listening sockets.
None of them is responding anymore until I hit pause/run.
I just recently saw this with a G120 Cobra 2 board that I updated to the latest firmware and using VS2012
With the debugger not attached the application runs without any pauses but I am seeing something strange with it just now that sounds similar to your issue.
Then I start the application, it starts but then I see it pause. I then hit pause in the debugger and then run and away it goes. Every now and again without anything being touched, it seems to just hang and you then pause and run and away it goes again.
@ Dave McLaughlin -
Thats exactly what I see here.
I’m not sure if I shold say ‘Nice that it’s not only me’
Would you say this came with the new Firmware or with VS2012?
When you pause the code, does it often break at a certain location? Perhaps during a network or file read() or write()? Or does it seem to randomly get stuck anywhere? Is it just the TCP thread that tends to get stuck, or do others as well?
@ Gus, my project is quite huge and requires a special environment. If I get the chance to provide a small project I’ll send it.
At first I recognized this problem using the NETMF FTP Server.
When accessing it with FileZilla it suddenly stopped respondig. Pause/Run makes it working again then.
@ John, Usually all threads are at waiting/blocking call like Socket.Accept, Socket.Poll, Event.WaitOne.
I can not remeber seeing a thread beeing at a ‘normal’ line of code when this happens.
Finally i’m sure that this is a debugger related problem.
It ran all night and was responding normally this morning and it did not reboot.
@ Dave When you press pause, one of the threads will always be stuck at p.Run() in a Gadgeteer app because the main thread calls that to run the Gadgeteer dispatcher. If you want to see where other threads are stopped at in your application, while debugging, goto Debug > Windows > Threads and double click one of the threads in that window to be taken to its current location. That should let you know where other threads are paused.
@ Reinhard When you pause and notice the code stopped at a blocking call like Accept or WaitOne, as soon as you hit run or F10 to step to the next line, does it immediately unblock and continue? If you do see it blocked at a normal line of code, please let us know.
I do still have this issue on large Projects.
I have the feeling that the debugger on the module seams to stop if ether there are a lot of waiting threads or if there are waiting threads plus other threads with high load.
Since my college never complained about it I think it’s no (or no big) Problem on smal projects like he writes. He only makes small projects to check the Hardware.
These only use one network connection and a single worker thread.
I hope I can find some time soon to create a ‘minum’ Project which I can send to GHI to reproduce the issue.
