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.
1 Like
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.
Duh? ā¦
2 Likes
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ā¦
2 Likes
@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.
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
3 Likes