Did you switch the transport to FastSerial in the project settings?

http://www.visualmicro.com/post/2012/05/06/Configure-debug-for-other-types-of-se...

It's a good think or I would never know that someone had used the FastSerial system without problem. Thanks for feed back 

Are you sure fastSerial on your selected port is working at 57600. 

If I recall, APM uses 115200 on the main USB Serial and 57600 on Xbee serial.

You will see some rubbish in the serial window because apm outputs binary but that looks like the wrong sort of rubbish to me. You will get the wrong sort of rubbish if the speed is wrong. 

Edit: Try setting LocalSpeed and RemoteSpeed to 115200. It looks like vm is not forcing the default of 115200 for fastSerial. 

57600 won't work because ArduPilot is using 115200

Well, this is starting to get frustrating.  Yes, I was accidentally using the wrong speed, but unfortunately that wasn't the culprit.  I selected the right speed in the serial monitor and hard coded it into Micro Debug as suggested.  Still nothing in the trace window for APM, BUT I can upload a simple program to the APM board and unselect FastSerial, and debug works fine.

Ardupilot code upload and FastSerial:
http://claytonasmith.com/images/screen_2012-11-03_18-51-20.png
debugtest code and no FastSerial:
http://claytonasmith.com/images/screen_2012-11-03_18-58-40.png

Okay, I have just downloaded the latest ArduPlane 2.66 and debug worked first time. 

I am using an APM2 and left everything else as default.

You can see the serial window shows apm text messages mixed with binary and looks quite different to the output in your serial window which leads me to suspect the serial rate is different. 

Questions

What config settings have you made to your copy of ardupilot? 
Have you re-started vs since having these problems?
When ArduPlane starts, do you see similar text in the serial window as shown below?

Geez, someone with more desktop icons that me

And a few hints that might mean something at some stage...

Project properties

1) Validation Skip. 

Set to False if you are not altering the apm code in a way that might cause compilation errors. This will skip the "release" build of apm that happens prior to the debug build. (Saves time)

2) Breakpoint Throttle

The unconditional breakpoint example in the 50hz loop is a good example for me to use...

By default, for newer users and non fastserial users the breakpoints are throttled so that the 50hz loop will only run at about 8-12hz. Visual micro ensures an 80 millisecond delay between breakpoints. 

a)
FastSerial is more efficient than normal serial so you could change the project property called Throttle (ms) to, for example, 30 (milllis) which would improve the speed. Leaving the Throttle (ms) empty uses the default of 80ms.

or b)
Try setting "Throttle Enabled = False" to entirely disable throttling in which case apm will send as fast as it can but it is possible for the arduino buffer to overflow causing the debug to stop working or invalid serial packets to be received by the debugger

or c)
Set the breakpoint "HitCount" to 50. Because we are in the 50hz loop this should produce one debug breakpoint message every second allowing apm to function at full speed inbetween each breakpoint message

or d)
Set the "Hit Counter" project property to milliseconds and all the breakpoint "HitCounters" will no longer be treated as counts, instead the HitCounts will represent milliseconds. So a breakpoint "HitCount" of 1000 would produce a debug  message exactly once every second regardless of where you put the breakpoint.

Tim