my comment is that this is a great option as long as you only want to debug things. This isn’t a general approach that allows your code to run without the debugger attached; an arbitrary delay or button press are both options that can be used as-is on deployment and won’t stop the app from functioning when the debugger doesn’t get attached (eg when you’re testing with external power only, or when you just hit reset and don’t reattach the debugger)
@Mr_John_Smith Can you explain how to do this or does GHI have anything on it? Everything that comes up on Google is for .NET in VS2015.
@Brett Thank you, I have a decent amount of Thread.Sleeps in my code already but will put more at the beginning. It is definitely getting past the deployment stage and failing at attaching the debugger.
But what would cause USB device not to be recognized randomly with Windows? I still get a fair amount of intermittent connection, on both boards I have, but one is definitely worse. I want to avoid having to reset every time I deploy code as I did not have to do this on the development board - the only times I reset it were on accident and I broke a number of things as a result but it loaded and ran good 99% of the time even with my ignorance of the debug attachment process.
if it truly is different between a development board and code and your production board and code, then you should investigate more - probably hardware issues first.
The answer about debugger being active is to use System.Diagnostics.Debugger.IsAttached and wait for that to be true.
1 Like
alright thanks I added that, hopefully it takes care of the issues
Sometimes reflashing the firmware, down to the loader helps. Just this afternoon I was having problems with a cobra 3. Putting it into boot loader mode and flashing it over seems to have sorted its bad behavior out.
@Mr_John_Smith So far so good since I added the deploy loop at the beginning as well as moved most of my code out of main. Just stuck on my I2C displacy still let me know if you have any advice
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