Main Site Documentation

G30 USB Debug Inconsistent connection


#21

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. :slight_smile:


#22

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


#23

you have fixed the symptom not the problem.


#24

So what do you suggest I do and what is the problem?


#25

Why does putting a sleep at the beginning of the program allow the debugger to attach? Is this a condition you expected?


#26

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.


#27

Duh? …


#28

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().


#29

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…


#30

@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?


#31

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.


#32

@Dave_McLaughlin Yes I did have that exactly but I moved it out. Is it safe to have that in main?


#33

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.


#34

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