I am on Windows 8.1 using Visual Studio 2013 with the latest version of visual micro. My program compiles fine but when I start in the debugger, I get a message in the serial console that its paused. When I click on the expressions window, it goes away and the debugger is crashed. I have to restart visual studio to get the serial monitor to work again after that. I am using arduino IDE 1.6.4 and a Arduino Uno at 115200 baud. I just have the simplest example program (blink and led).

One other point to note. Because we use serial, if the debugger closes and re-opens there is a possibility that the arduino will still be paused at a breakpoint. However the debugger won't know about it. 

In this case F5 won't work but you can use the serial monitor to send the letter 'c' to the arduino. This will force a "continue".

Alternatively switch on the DTR checkbox on the serial monitor. This will force the arduino to re-boot each time the debug/serial begins (ie: when the serial monitor is opened). The DTR checkbox will work on boards such as Uno, Due it's a standard part of how arduino serial works. This is actually the reason why an upload will always cause the debug to start again, one thing the upload does is set the DTR to cause the board to reset.

Hope this makes sense.

Hi,

Great. You can play with docking you will find it possible to have the serial monitor small in one corner or position and the expression in a different location. It sounds like you had them both in the same dock group. If you move the undocked serial monitor without holding the CTRL key then you will find many more potential doc positions.

The expression window says waiting for data if you have not defined any breakpoint watch {expression/variables}. Otherwise it means the first breakpoint (with watch expressions) hasn't yet been hit. 

Have you set any watch expressions and/or "when hit" message (seen the docs?)

Thanks

Hi,

Yes everyone would like that There is a new version under development that will provide auto discovery of locals and many other things, also better support for arrays etc. 

However the docs and the video show what is currently possible, it's an alternative to serial.print messages in the code as opposed to a full debugger replacement.

The advanced version, when it arrives, will be a free upgrade for existing customers.

Alternatively you can use your code in a native atmel gcc/cpp project and debug with a hardware programmer. Then you get native atmel debugging which is very detailed but difficult to configure.