It seems that my problem was trying to allocate a Output port, which caused the entire application to hang. Funny, this code used to work fine before.
Everything is running flawless with 10 s sleep at the start or the debug attached loop, have not gotten a single USB disconnect or unrecognized device or any error whatsoever since I implemented to techniques. That should definitely go in GHI documentation
you have fixed the symptom not the problem.
So what do you suggest I do and what is the problem?
Why does putting a sleep at the beginning of the program allow the debugger to attach? Is this a condition you expected?
I’m pretty confident that, as I said earlier, the problem is in your code - the way it’s constructed doesn’t let the debugging engine get any processor time to attach to the debugger when requested. You need to explore your code.
I don’t understand how my code should be structured differently. This is my first time working with NETMF so it isn’t as obvious as “Duh” to me. Too many threads? I moved everything out of main().
You have been doing NETMF for six months. Your novice excuse has expired.
I never said that there was a problem with the structure of your code.
Read the prior posts… your problem has been explained several times. I mean the problem with your code…
back into silent mode…
@Mike I mean this is my first time testing a fully programmed micro controller. Before I was just testing a couple pins at a time but now everything is combined. I have done everything suggested but am looking for specific examples on how code could be too tight. Is it ok to call a method like Initialization() as the only thing in main? Or do thread.start() instead? If I remember correctly its better to keep the threading to a minimum. The code already has Thread.Sleep(10) pretty often. Like every few lines.
Will this type of scenario cause problems any time other than debugging?
Do you have an infinite loop at the end of MAIN after you do all the initialisation?
This is usually where I do all the main processing for the programme through the use of flags with threads handling the IO and network etc.
@Dave_McLaughlin Yes I did have that exactly but I moved it out. Is it safe to have that in main?
In all my coding main is never allowed to exit. That would constitute a program exit. Probably not an issue with NETMF but on a real OS this would cause the OS to free up the resources etc.
Better to have a while loop with nothing more than a thread.sleep(-1) as this will be infinite and prevent main from returning.
that’s of course also an issue for NETMF/TinyCLR OS since your program stops to exist
you don’t need the while loop, a simple thread.sleep(timeout.infinite) as last command is enough