Is your breakpoint in a condition or has a condition been applied? If not and it is in the loop() or fast running function then the serial buffer on the arduino might be overloaded.

If you close the ide then re-open it. Do not open the sketch project but instead open the serial monitor. You should see the debugger messages. Please post a couple of them.

Thanks

Tim, Charlie - I understand how conditions can cause a breakpoint to not hit.  I created a simple test program that had a INT in setup and the int++ was done in the LOOP with a delay then incremented again.  Insanely simple - break never was hit - and as I say - I can see the TX light blinking (prob sending the break data message - but nothing is displayed.

I have started using Arduino 1.5.5 - can't imagine that has anything to do with it...   it is just that the most simple breakpoint or hitcount won't show a thing!   

Wondering if the serial ports have gotten hosed or something...
=A.

Ok - think now I've done those steps.  The Project compiles and runs - but all logic isn't working yet - hence the need for debug.   Meaning to say I don't think there are currently any serious coding errors in it that would cause the serial port to not respond - or other bizarrness.

I've set ONE break point in SETUP where a call is made to run a flashing-8's routine.  Very simple - only executed once per run of the Project (it has 6 .ino sketches).  And the breakpoint message does not show.

I closed the Project, left VS running and Serial monitor open. Reset the Arduino to have it run thru SETUP again -   All that shows in the Serial Monitor is "Port Open" - no debug message, no debug windows show as it usually does.

Here is the SETUP code where the break won't hit:

#include <Arduino.h>

#include <MenuMgr.h>
#include <I2C.h>
#include <RESRotEncLib.h>
#include <Bounce.h>
#include <BEDstep.h>
#include "MicroIndexer.h"  // All defs for this project in this file

// Instantiate a seven-seg Display Object
I2C TheDisplay;

// Instantiate Motor Object
BEDstep TheMotor = BEDstep(STEP_PIN,DIR_PIN);

// Instantiate each Menu Object
MenuMgr Count_menu;
MenuMgr Deg_menu;
MenuMgr Speed_menu;
MenuMgr Clear_menu;
MenuMgr MicStp_menu;		// micro step menu item

MenuMgr CurrentMenu[4];		// Array of menu items orded by MENU_xxxx

void setup() {
	// System Setup Set up I/O pins, init various items
	initMenus();
	initSwitchs();		// setup switches as inputs
	//mpin_init();		// set up motor pins
	SevenSeg_init();	// init display, start oscillator
	flash_8s();			// Show the display is alive
} 

Hi, thanks for the serial output. It shows there are 3 breakpoints working fine. That one breakpoint is passing back watch expression data. No breakpoints cause a break, the arduino is in "Trace" mode.

So the debugger should be displaying the correct trace and watch data. Cab you post an image of the Ide when debug is running (or supposed to be running). I would like to see the micro trace output window and the serial window settings while debug is supposed o be active.

Thanks very much for all the info

Please email images to info [at] visualmicro.com thanks. Also please email copy of your sketch folder if possible so I can see code and your settings.

Please switch project property "enable break/pause" to False while you test this. Then we don;t have to wonder if the system has paused at breakpoint waiting for F7 or F5 etc.

Thanks

Thanks for the email. According to the config only one breakpoint was included in the last upload to the Arduino

An extract shown below (let me know if you want it removed) shows there is a breakpoint in the            case MENU_COUNT: statement. 

The code on the Arduino appears to be a different config that was shown by your previous serial output and also different to the current source code. Can you please confirm which code and breakpoints have been uploaded. I also suggest adding a breakpoint on void Motor_Step() { so that you can watch MenuIndex and see what value it contains.

One other point is that the comment in the code suggests the breakpoint is in code that is called for each loop(). This can flood the arduino serial, I suggest using the breakpoint condition to check to see if something of interested has happened or for exception reporting. This will reduce the serial output dramatically.

Thanks

 <BreakPoints>
      <BreakPoint Index="1" Name="MotorHandler.ino, line 14" Id="06f3a86b-ae00-410d-93d6-44d4bbbc2c87" Enabled="1" Message="ROTATE!" MessageTextType="0" PreProcessedMessage="ROTATE!" Condition="" ConditionType="1" CurrentHits="0" File="h:\ard\sketches\microindexer\motorhandler.ino" FileLine="14" FileColumn="1" FunctionName="Motor_Step()" FunctionLineOffset="4" FunctionColumnOffset="1" HitCountTarget="1" HitCountType="1" Language="C++" LocationType="3" Tag="&lt;vmbp Id='cb019047-c11e-4be5-8957-a3c6ab99e32e'/&gt;" Type="1" ToString="System.__ComObject" BreakWhenHit="0">
        <Source>7
8	//Called from LOOP when System is IDLE to check for RUN or JOG button press
9	// RUN/JOG switches set a MOTOR_STATE which allows 1 run cycle.
10
11	void Motor_Step() {
12		switch(MenuIndex) {
13		case MENU_COUNT:
>>BREAKPOINT ON THIS LINE>>			rate = .7;
15			stepct = long(CurrentMenu[MenuIndex].get_display());
16			TheMotor.rotate(stepct,rate);
17			MotorState = MOTOR_IDLE;		// Stepping done - set motor idle
18		break;
19		case MENU_ANGLE:
20			// set by degrees
21		break;
22		}
23	}
</Source>
      </BreakPoint>
    </BreakPoints> 

Well done. The upload will certainly of helped to ensure we have the same code running as on the mcu. That then sounded like a timing issue where the serial connection had not started properly. Clicking the show serial monitor icon does re-start the serial.

For the next release due shortly we are working on the serial connection which now also supports network and will ensure this area is looked at more closely.

Thanks for the update

Hi,

I am sorry you have having a problem. You are the only person reporting this problem so we have to consider your config and code to allow us to replicate or understand what is going wrong. This is not to suggest you are doing anything wrong but to allow us to discover where the confusion is and to improve the wiki with a solution.

We can easily see what is happening in the code. Switch on "tools>options>visual micro>compile>always show builder folder" then compile and upload a debug version. The Micro Build output will show you the build location. Open the location, zip it and email to info [at] visualmicro.com. Thanks!

This problem will be related to serial or a breakpoint conditional logic. Please keep in mind that there is nothing magical about the debugger, it just adds serial messages to a temp copy of the code prior to upload. This means that we use well proven Arduino code (Serial) and its easy to see what the code is doing and why.

Thanks

Hi Alan,

Got the file but can't find any breakpoints in the code. 

Where do you see your breakpoint in normal code view? In which source code file and at what line number?

Thanks

Sorry - didn't realize you wanted me to add a BKP.  Put one at line 66 in MicroIndexer.uno - that is the "main" file.   

I just tried it and got nothing.  The program is running well now, just need breakpoints to check various values for the stepper delays and such...

Not getting email notifications of your replies - and I do have the check-box selected...

Thanks for the email with the files. It was my fault previously for not explaining properly. Nice code!

I see the problem. This is to do with the way the injected debugger has to work. We inject serial statements into the temp copy of the code, at the END of the line of code. Normally you might expect a debugger to stop or report at the start of a line but with code injection it is easier to report at the end of the line.

In doing this we have to workout how to add a serial.print() to the end of the line of code you have added a breakpoint to. As you can imagine some code lines are easier to workout an "end point" than others. In the case of one line if statements, for example, visual micro attempts to change the code line into a multi-line if statement so that it can then insert the special breakpoint serial messages.

Yhe debugger overviews do try to make the point about adding breakpoints to as simple as possible lines of code. It's not a perfect science and we always look to improve the system based on real world experience.

Your example shows that you placed a breakpoint on a switch statement and I guess it now makes sense to you that this would be a problem. It's a tough place to inject a breakpoint notification message. Your final code actually looked a bit like the following example, after the debugger had done its stuff. 

Notice the serial.print is in an invalid location, I am surprised the compiler didn't pick this up. Oops!

if(SystemState == STATE_IDLE) {
switch(MotorState) { Serial.print("Breakpoint here!! Ooops!");
case MOTOR_IDLE: 

Actually if you had inserted the breapoint the line before I think it would work okay. The breakpoint would only be hit when system state is idle and a "When Hit" condition of "Motor idle = {MOTOR_IDLE}" should show the current Idle state.

Does this make sense. It's a weakness of injected debugging and something we will improve gradually over time. I notice your code is very neat and makes a lot of use of nested single line statements. These will present a problem and will require some thought by you. Visual Micro can't currently make good judgement about where complex single line nested statements start and end so best to keep away from them.

Normally to debug Arduino, Serial.print statements are manually added to the code and must be removed at some later stage. This debugger does prevent the need to hack the code in that way but it might be that you still need to alter a few one liners to be enclosed in braces { } when diagnosing code issues.

Your code is so neat I am not surprised you have had so many problems. I guess the biggest point I can make is to be clear that we inject to the end of a line of code and it is not an exact science when faced with anything other than simple and clear bracketing {}. 

Sometimes it is also useful to note that because we inject you can place a breakpoint on blank/empty lines of code but please keep in mind how a new line of code will affect program flow {}.

Whilst not a perfect solution I hope this helps remove some frustration an thanks for your patience

Yes it's solid as a rock on simpler code.

Thanks again