Is there a way to disable the debugging interface totally?

NETMF & Gadgeteer
1

Hello,

Is there a way to disable the debugging interface on the FEZ Domino? I’ve jumpered the Mode pin, which switches the debug interface from USB to COM1, but is there a way to make it so I can have USB, COM1 and COM2 available for use?

Thank you!

2

You can release in production, but you can’t just “undebug” the USB client and expect to gain something.

EDIT: I should say, the USB client is NOT a USB to UART bridge, like on a platform like the Arduino, for example.

3

Sorry I’m not fully grasping what you’re trying to say.

I’m using the USB client as a USB Mass Storage Controller and the way to do that is to move the debug interface from USB client to the COM1 serial port on the FEZ by jumping the Mode pins. Then the USB is free to be used as a mass storage controller since the debug interface isn’t using it anymore.

I need the use of COM1 and COM2, so I’m wondering if there’s a way to turn off the debug interface as a whole, instead of just relocating it to COM1, where I’m unable to use COM1.

4

I believe that if you set your target in Visual Studio to Emulator or do not run VS at all (because you are not going to debug the device), then tFez will not connect to any debugger and therefore USB and COM ports will be available for other purposes. If you do not connect a debugger, then the Fez won’t try to use any ports for debugging.

5

NETMF needs an interface, even if you are not debugging, to send out boot messages and other runtime info. Like your system is crashing and you have no idea why…you need the port to check for exceptions.

We could add a fake port to disable all this but with 4 COM ports, this is not extremely important. Those messages become really important at one point, even after you ship product.

6

That is really good to know. And it makes perfect sense. Thanks.

7

I have a Fez Domino - so only 2 COM ports and both are used in my application. I really need the Mass Storage to appear on USB and at that point I don’t need the debug interface.

Is there any way to convince the Domino in software to drop the debug interface (or use a dummy COM port) and let me have Mass Storage instead?

8

See the brochure about using a secret COM port 4:
http://www.ghielectronics.com/downloads/FEZ/Domino/Broch_FEZ_Domino.pdf

You can use USB to serial on Domio too.

9

So is it possible to relocate the debugging interface to COM4 for a production release?

10

I’m using all the AD pins and all the uext pins too. i’ll try a reshuffle.

What about being able to direct debug to a in internal memory stream that works like a fake com port? That way we can re-send it over Cdc, write it to mass storage or put it out on an lcd or ignore it completely.

11

You can switch debugging to one of the serial ports not being used. The pins are not exposed but you do not care on your case. I can’t remember if USBizi can use any serial port for debugging!

12

USBizi can only use USB or COM0.
You can use COM4 instead and not COM0…
This is currently a must. We can look for more options in future.

13

I moved the RFID reader to COM2 and I’m now debugging on COM1. I can mount mass storage and debug over serial - yay!

Now I have a new problem though.

The RFID reader now connects over TTL to COM2. I set it up like this:


                _SerialPort.BaudRate = 9600;
                _SerialPort.DataBits = 8;
                _SerialPort.StopBits = StopBits.One;

                _SerialPort.DataReceived += new SerialDataReceivedEventHandler(_SerialPort_DataReceived);

                _SerialPort.ReadTimeout = 100;

                if (!_SerialPort.IsOpen)
                {
                    _SerialPort.Open();
                }

I scan the RFID tag but the event doesn’t fire at first.

As soon as there is incoming activity on COM1 (PC sends data to Debug port), the event fires and the buffered string comes through on COM2.

It’s almost as if incoming data on the debug port releases something on COM2.

Any ideas what could be causing this?

14

First open the port, then subscribe to the event !

15

I’ll try that - but this worked perfectly when I was using COM1 for the RFID reader before. It started happening after moving the RFID to COM2 and debugging on COM1.

Why would COM1 and COM2 even be related in any way? Surely debugging on COM1 cannot have an influence on COM2? The app isn’t hanging because my keypad thread still responds.

One thing I have noticed is that there seems to be some cross-talk. My wires aren’t shielded and the debug traffic seem to introduce “noise” on COM2. What I can’t understand is when there’s lots of traffic on COM1, COM2 suddenly works. When COM1 is quiet, COM2 doesn’t fire events.

Should I perhaps tie COM2 low through a weak pulldown or perhaps high? Is it electrically different to COM1?

16

Thanks Eric. Subscribing to the event after opening the port fixed it.

Also mentioned here… http://www.eggheadcafe.com/software/aspnet/33736502/serialportdatareceived-does-not-fire-without-debugger.aspx

Thanks all for the help.

17

You’re welcome :wink:

18

Is it true for the spider ?
I try to use the COM0, but I have an error message…(COM0 is used by the USBH ?)

19

Please start new tread with details about your setup.