Debugging with a serial transport

It would be nice to have some examples of how to use COM1 to do debugging over a serial port, that would make playing with the new USB client stuff more practical.

See this:
http://tinyclr.blogspot.com/2010/03/debug-and-deploy-over-serial.html

Hmm,

If you have an Arduino laying around, you might able to a ghetto “hack” it for deploying and debugging over USB (Virtual seral)

Connect TX on the FEZ to theTX pin on the Arduino, RX on FEZ to the RX pin on the Arduino and the connect the GND to each other.

Thanks Mike. That page will be handy as folks start playing with the new USB stuff. Somewhere I have a couple of the Parallel USB2SER boards: http://tinyurl.com/2bbxa7p . I think these would work better in my case than YAS (Yet Another Shield).

Even better, I just remembered I have one of these little guys that I bought but had not found a good use for yet: http://www.poscope.com/product.php?pid=4 . Any easy solution for serial/USB conversion for prototyping.

You can use anything to connect the serial port to your PC for debugging, through RS232 or through serial<->USB converter. The shield is easier/better for someone not wanting to do any wiring or soldering.

Since I don’t have a RS232 shield, and would rather not have to plug in YAS (yet another shield) I am trying to use a Parallax USB2SER board that I on hand. I have it wired in to COM1 and can ping the Domino.

When I try to deploy a project I get the following:

[quote]------ Deploy started: Project: LCDLiveText, Configuration: Debug Any CPU ------
An error has occurred: please check your hardware.
Request failed
Source: Microsoft.SPOT.Debugger
Stack :
at Microsoft.SPOT.Debugger.Engine.Request.Wait()
at Microsoft.SPOT.Debugger.Engine.SyncRequest(OutgoingMessage msg, Int32 retries, Int32 timeout)
at Microsoft.SPOT.Debugger.Engine.SyncMessages(OutgoingMessage[] messages, Int32 retries, Int32 timeout)
at Microsoft.SPOT.Debugger.Engine.ResolveAllAssemblies()
at Microsoft.SPOT.Debugger.VsProjectFlavorCfg.Deploy()
at Microsoft.SPOT.Debugger.VsProjectFlavorCfg.<Microsoft.VisualStudio.Shell.Interop.IVsDeployableProjectCfg.StartDeploy>b__0()
========== Deploy: 0 succeeded, 1 failed, 0 skipped ==========[/quote]

I’m certain I’m doing something stupid, I just don’t know what!

OK, I KNEW I WAS DOING SOMETHING STUPID!

The program I had on the Domino used Di0 and Di1 (Com1)for other purposes. So as soon as I reset the Domino and tried to communicate with it over serial, the coms would start and then as soon as the program that was on it was started up, it re-purposed the pins being used by Com1!

I loaded a different from via USB and then switched back over to serial debugging and everything worked a treat.

This only goes to proves Jeff’s first law of life and design: (from whom did I steal the idea for ‘laws of life and design’?)

#1) It is always safe to assume the problem your facing is your own fault; 99.9% of the time it will be so there is no sense wasting all the effort it takes to blame other people.

Sounds like you are having fun:D

Wouldn’t it be a pleasure to enjoy the little that remains ? :stuck_out_tongue: I think it’s the main reason why we are always inclined to think/act this way :wink:

I’ve been looking at the information on the beta and can’t wait for its release. In the meantime I’m getting my FEZ Domino ready for it and I have a couple of questions.

  1. Should you solder a 2 pin header to the mode pads? That way you could use a shunt to enable/disable the Com1 debugging mode.

  2. I have a prop plug and other than the pinout it is identical to the USB2SER so it should work with Jeff’s idea.

  1. Yes
  2. Yes

[quote]1. Should you solder a 2 pin header to the mode pads? That way you could use a shunt to enable/disable the Com1 debugging mode.

  1. I have a prop plug and other than the pinout it is identical to the USB2SER so it should work with Jeff’s idea.[/quote]

A1. That is what I did. I used a ‘stubby’ jumper so that a shield could still be plugged on top.

A2. That looks like it will work just fine. I hooked up the reset pin as well and found out that unless you have the USB cable plugged in it won’t let the FEZ come out of reset.

I have some right angled headers that shouldn’t interfer with any shields