Yes remove jumper and all goss back to USB
@ kurtnelle : This is how I fried COM1 [url]http://www.tinyclr.com/forum/2/870/[/url]
The Domino seems OK apart from these pins which just don’t work anymore.
I am worried that there may be other issues that aren’t apparent yet and I’ll think it’s an issue with my code.
Ok so I soldered the pads and put in the jumper. Removed the jumper to load the app then put the jumper back. Rebooted and the prompt to install a new device came up. Then windows 7 was unable to find and install the device driver.
So then : Does anyone have a USB CDC VCOM driver for windows 7 32 bit?
The documentation tells you where the CDC driver is and give you an example source code
I’m having a hard time figuring out where the driver is, but I know where the example code is. Just to be straight this is the : USB VCOM driver that I’m looking for right?
I just checked the “CDC class” in documentation
http://ghielectronics.com/downloads/NETMF/Library%20Documentation/Index.html
and it says “The driver is available here:…”
please read the documentation carefully 
Oh that documentation! Wouldn’t it have been simpler to ship it with the sdk? Thanks Gus.
EDIT: Aw… it works so nicely!
it is in the SDK!
:o
i’m having the same problem…
i have a domino, and have soldered pins onto the mode pads
with or without the pins shorted (with a jumper) the device still boots into debug (i.e. shows up as a “Debuggable .Net Micro Framework Device” instead of a COM port
running the app in debug works via the virual CDC however
i don’t have a serial shield… is there something else i need to short/connect to get this to work?
Please take a picture and show your setup
If you short that jumper then you will need a serial shield to debug or load a new program.
If your code uses the combined Debug/CDC driver then the board might ignore the jumper all together. As in, the board start up, sees the jumper is shorted, starts up in Serial Debug Mode. But then your code loads the USB Debug/CDC driver which reverts debugging back to the USB port…
Wasn’t sure what you meant by picture of my setup, so here’s one of the board. I’ve soldered a header onto the debug pad, and that is where I am placing a jumper.
What Errol says might have something to do with it… I don’t have a serial shield, so I’m trying to juggle this via USB.
I’m using the CDC plus debugger example project…
At the moment, without the MODE pin shorted, it will boot up and give me debug AND the CDC, and all works great (so far).
If I apply the jumper, nothing changes… probably for the reason that Errol describes.
In the code it is calling USBClientController.StandardDevices.StartCDC_WithDebugging(). If I try to change this to USBClientController.StandardDevices.StartCDC() and debug I get an “CLR_E_INVALID_OPERATION” exception with or without the MODE pin shorted (I assume because you can’t start CDC if it detects the USB is in use for debug). If I try to boot the device (not via VS) with or with the short, it doesn’t seem to boot (I guess the same exception is occurring)
I read something about the COM1 RX pin… do I need to do something with this because I don’t have the serial shield attached? i.e. will the board ignore the MODE pin because it doesn’t think I have another valid method of debugging?
What I am aiming for, is that when I leave the MODE pin open, I get both the USB debug interface AND the virtual CDC so I can develop/test. Then when I short the MODE pin, I just get the CDC for use in my application.
If you are going to use USB then I highly recommend RS232 shield or USB-serial eblock. If oyu are just starting out and want to switch back and forth wihtou RS232 shield, you will only hit problems.
MODE pin only changes the debug channel if you set it before powering up the board.
To user serial debug, you need the jumper on MODE and a serial shield or similar (RS232 shifter).
You can debug and use VCOM over the USB device.
Both these are a little different.
OK… based on the replies and my findings so far, I’m going to assume you cannot “disable” debug AND use USB for CDC unless you actually have the serial shield… i.e. if you don’t have a shield, the best you can get is debug only, or debug+CDC
I was hoping there was some way debug could be disabled and still use USB/CDC so the device could be deployed without a serial shield.
Thanks for the feedback.
You can keep the debug mode as serial and use the USB as a CDC device
You can keep the debug mode as USB and use VCOM for serial communication
You need the serial shield to communicate with the Domino from Visual Studio or MFDeploy when the mode is Serial or if you want to use serial to communicate with a terminal.
Quote: “I was hoping there was some way debug could be disabled and still use USB/CDC so the device could be deployed without a serial shield.”
Is there really no way to make it happen for the FEZ Domino V1.1 without additional equipment (serial shield) to use the CDC via vCom over USB ?
An definite answer from an op would be really appreciated.
Look up two posts, and then read Rajesh’s reply. You can’t disable debug; you can move debug to serial or you can leave it on USB; you can run USB+CDC but its not going to be supported. What do you actually want to do and why?
I was more focussing on the “you need the serial shield to communicate when in serial mode”.
Which I read as a hardware requirement. (It’s pretty late over here)
goal:
1 deploy via USB
2 switch mode by jumper to "debug/deploy by serial"
3 communication between app on FEZ Domino to PC over vcom with CDC using the USB client port on the device
why:
- sensors
- motor driver
So far so good (1-2) but the vcom decides not to show up for the party (w7 64b, FEZ Firmware up to date, drivers installed as advised by the manuals).
Reading material varies in degree of usefulness … next approach testing on legacy/other OS and more of rtfm.
Any suggestions where to attack this problem first?