I'm using the debugger in VERY simple sketches to build my understanding of various elements of the Ardunio code environment.  I've done some simple calculations in the setup() function and place a breakpoint on one of the operations. the sketch uploaded ok... the Expressions window pops up with a gray 'waiting for breakpoint data'...  and nothing happens.

I even added some (dreaded!) Serial.print statements which work under Arduino 1.0.3 - but I see no output from that - guess I may have closed it's window but can't find it...   

Anyway - I've been having this issue for some time where the breakpoints just never hit.   Is this a common issue? Have I stepped on something and 'broke' VM? 

=Alan R.

Hi There,

Few things

1) In the current version of vm the serial monitor only outputs data when it receives a "new line" char. So if you add a serial.println() that will make the display work correctly.

2) Debugger breakpoints are shown in the Trace Output window. The only time that I know breakpoints can fail is if you have too much of your own manual serial.print() data. In this case you can either remove your serial.print() statements or use a different serial port or softwareSerial for debug. If you have too much of your own serial print data then things might appear to work sometimes and not others.

3) The "waiting for data" in the expression viewer will only show data if you have set debugger message/expression watch. Such as "Hey! Millis = {millis()}" or "{a}{b}{c}". You are correct that the "waiting for data" message will also remain if breakpoints are being lost to serial.print() overflow.

4) Breakpoints are TracePoints unless you set the project property called "Enable Break/Pause=True"

5) If you have used your own serial.print() statements then you will have probably used the "serial.begin(baud)" syntax in your arduino code. If so, then the baud that you specify in your code must be the same as the project property called "Remote Speed". When you change "RemoteSpeed", Visual Micro will automatically adjust LocalSpeed to be the same (unless you have overridden the defaults)

If your code overrides the default debugger baud (115200) and you have not adjusted the Local/Remote Speed property then breakpoints will not be hit.

6) Do not attempt to put a breakpoint on lines of code that print or read serial messages. There is little point of doing this, and, because the debugger uses serial it is just too much for the arduino and can overflow the buffer regardless of amount of data.

7) If using the setup() instead of loop() for testing or using breakpoints then you should switch on the DTR checkbox on the serial monitor window. The setting will be retained by vm when you re-start visual micro. 

The DTR setting controls if the arduino should re-boot when you open the serial monitor. Turn it on the force the re-boot.

Consider that after upload the arduino will start very quickly, before a window can be opened. In that case the arduino has already completed the setup() within a few milliseconds. 

The DTR is ON in the arduino ide by default and can not be switched off. This means that in the arduino ide every time you open the serial monitor the mcu has to re-boot which is not often what is required.


Summary

If these tips don't help then please email your .sln and all of the files and sub folders of your sketch to info[at]visualmicro.com.

Thanks

Great. 

The setup() works the same as loop() for breakpoints. If you are using the std serial port then vm should have automatically enabled the dtr when the debugger starts. 

However there might be a bug that if you fill in the "LocalPort" or "RemotePort" project property and it is the same as the default then the dtr might not being forced on. I need to test this.

BUT, if you have switched on the DTR manually I would expect breakpoints to ALWAYS work (if serial usually works)

Look forward to hearing how you get on.

ps: Depending on serial or serial1, Leonardo is often better at 56k, software serial is always better at 56k on all systems.

Hi there,

The debugger uses serial, I think timer 0 breaks that. An ftdi cable and software serial might work better for you.

We certainly need better documentation. There is a fine line between too much and too little information for many users. 

How about if I add this statement to the debugger page?

In the background, the debugger uses standard Arduino Serial. If your code will interfere with Arduino Serial then it will interfere with the debugger unless you change the "RemoteTransport" project property.

Found another tiny 'gotcha' - Breakpoints in setup() don't seem to hit if you do a cli() in setup.  My sketch was hitting BP's yesterday, and today I added the cli() and the debugger went to sleep!        On the odd chance I commented out that bugger and VOLIA!  my BP's were back.  Not a surprise as I think about it, but also wouldn't hurt to be part of the Debugger info...

=A.