Hi Eric,

I am sorry you are having problems. 

The debugger does not work with Arduino versions earlier than Arduino 1.0 which includes changes to Serial.print().

Sorry. I hope you manage to update your project to a version of Arduino from Nov 2011 when Arduino 1.0 was released. Arduino 1.0 had a few bugs, you might find the current Arduino 1.0.5 release is the most robust and closest match.

It might not affect you but might be worth knowing that the 2560 with Arduino 0023 will not allow a program size > 128k.

EDIT. We will make this clearer on the web site. It used to be stated clearly but the message seems to be lost. Thanks for the report. Let us know if we can help.

Hi Eric,

That is working. Please watch the youtube video on the debugger page.

By default the break/pause is not enabled which prevents novice users from crashing their robot or drones There is a project property called Enable Break/Pause which when set to True will stop at any breakpoints that do not have the "Continue Execution" "When Hit" property set.

The required watch expressions are are set via the "When Hit" property for example this will watch millis()

{millis()}

and this will watch millis but also give a textual message

Millis is currently {millis()} 

and this would allow a variable called abc to be updated without recompiling the Arduino code.

Millis is currently {millis()} and abc is {abc=?} 

All changes to breakpoint properties require a recompile and upload.

Hope his helps

Thanks for the useful pic. 

It looks good except that "Continue Execution" would need to be unchecked to break.

One other important note is that the software debugger currently injects code at the end of a line. If a "loop" or "if" etc. statement is encountered then the breakpoint is injected into the first line of the "If" or loop etc. If a one liner existed then it is transformed (in a temp code copy) into a multi-line. It's not an exact science so it is best to place breakpoints on lines of code with a simple structure. I mention this because in your example the breakpoint will only fire if power == POWER_OFF

We certainly DO need better documentation! Hopefully sales of the debugger will provide the resource to do this and hopefully allow the main tool to remain free. It's a bit of chicken and egg I know 

For now this is what we have

Youtube overview http://www.youtube.com/watch?v=fFM8_RhIG0U

Debug overview http://www.visualmicro.com/post/2012/05/05/Debug-Arduino-Overview.aspx

How to modify variables while the arduino is running http://www.visualmicro.com/post/2012/10/24/Modify-Arduino-Variables-During-a-Deb...

Debug wiki http://www.visualmicro.com/archive.aspx#Arduino-Debug

Hope this helps. Please ask questions if you can find an answer on visualmicro.com or forum. It will help to understand what is confusing or in need of explanation. Thanks

Hi,

The only time I have heard of this problem is when someone put a breakpoint in the initialization of a class. This caused the Arduino to reboot because the Arduino Serial object (used by debugger) had not yet been instantiated when the users class was instantiated.

You have found the build folder. It can be reported during builds by switching on "tools>options>visual micro>compiler>always show build folder". In this folder you will find a [sketchName].cpp with injected code but also if you have cpp files with breakpoints they will also exist in the folder with injected code. Please zip and email the entire folder info [at] visualmicro.com.

Thanks