As I am playing with integrating FezTerm with my application I’m finding needing to to a ‘Break All’ to get the debugger to reattach is a PITA. It leads me to wondering if there is a way to automate this. I’m thinking of something like hitting a break point right before calling “USBClientController.StandardDevices.StartCDC_WithDebugging()” that would resume the program and then break.resume a few seconds later (after CDC is started.)
Any thoughts?
Have not been able to find an automated way either. If it really becomes a pain, I guess could always use a real serial port on the fez.
I found you can use
System.Diagnostics.Debugger.IsAttached
in your code to find out if a debugger is attached. But the action to break and restart has to be initiated in VS though. Oh, well it would be nice 
This is something not officially supported in netmf so the fact it is working is a surprise to everyone involved in netmf!
Can you use just CDC? You can still load apps from USB but then add jumper to mode pin and USB is now CDC.
I could Gus and I could just as easily just use one of the Domino’s built in serial ports but it is just fun trying to see what might be made to work. In practice I would just use a regular serial port or CDC for a completed product or check some sort of mode button and enable CDC on booting the device if the button is pressed.
I understand. If you think about it, this is quite crazy! While you are in debugging session, FEZ disconnects itself and quickly comes back before Visual Studio think it is gone! What is more crazy, FEZ comes back with different interface, it is even on a different USB_PID!
I think the only to make this better is by making changes on Visual Studio side so it expects this behavior.
Also working on a project using serial for some side command work. I am side stepping the issue with another ft232 cable.
[url]http://staceyw1.wordpress.com/2011/03/18/connect-com-ports-to-fez-via-usb/[/url] Does take a board, but works good.
I’ve got an FT232 board that size from Parallax. It has been used for serial debugging on a FEZ before
[quote]I think the only to make this better is by making changes on Visual Studio side so it expects this behavior.
[/quote]
I agree I was thinking that hitting a break point before the CDC w/debugger was attached and then running some sort of macro might be the way to go. I found out how to insert such a macro on a break point but I’m still not quite sure what the best method of attack is.
No USB expert. But doesn’t USB support multiple active channels/devices per USB? Why couldn’t debug channel and multiple vcom channels all exist at same time? Wouldn’t that just involve driver changes on both sides?
You are right. It is a CDC + debug at once but the problem is BEFORE this change, it is only a debug interface…
So couldn’t VS make the change to its driver. Leave a hook open (or something) to attach a wating vcom. Not knowing the details, it is a 1000 foot idea.
One thing I just tried is to do a ‘CTRL + F5’ to start without the debugger attached. Then you can use 'Attach to process…" to attach to the FEZ. This is much more of a PITA than just using ‘Break All’ and restarting but might be an avenue to automate the process.
You can “attach to process” in NETMF? This is pure awesomeness! Didn’t know that…very cool
Yeah, the first time you do it you have to get things pointed at the FEZ, don’t remember all the steps. Second time it is much easier, you just have to set the transport to USB and it will see the FEZ.
coolness. Ultimately using the same mechanics however?