Before logging an issue, please update to the latest release of Visual Micro from the Downloads Page.

When Logging a Support Issue in the Forum, please ensure you have also:-

  • Enabled vMicro > Compiler > Show Build Properties
  • Re-Compile your program with these settings enabled
 
Save the new Output to a Text File and....
  • Click the Reply button and attach as .txt file OR
  • Click here to Email us with the file attached, and a link to your post
Support requests without the output above may be impossible to answer, so please help us to help you
 
Page Index Toggle Pages: 1 Send TopicPrint
Normal Topic unexpected program stop when debugging (Read 5122 times)
Robydid
Newbies
*
Offline


Posts: 4
Location: Italy
Joined: Oct 30th, 2015
unexpected program stop when debugging
Oct 30th, 2015 at 11:42pm
Print Post  
Hi,
I am having troubles with visual micro debugger on Visual Studio 7 and latest VM beta plug-in.
I am used to write low level code for Atmel and debug through debugwire tools (JTAG ICE-mk2) but some time ago I discovered your nice sw debugger and I must say I like it.
Unfortunately, debugging a small code to manage a rotary encoder push button, I have seen unexpected behaviour with VM debugger.
I used Arduino MEGA and SER3 for debugging (115.2kbps) to avoid mixing up data on a single serial.
I have uploaded a small program and placed 2 breakpoints. One breakpoint is in an interrupt routine and one in the main loop.
If I enable only one of the two interrupt everything is working fne independently from which breakpoint is active.
No problems also when the two breakpoints are active but the conditions of each breakpoint prevent the possibility that both breakpoints are validated within a short time...
As soon as the second breakpoints occurs within a short time (some microsends) from the first the program in Arduino MEGA suddenly hangs; "continue execution" flag is set on each breakpoint action.

Code (C++)
Select All
extern "C" {
	#include "init.h"
	#include "mytimer1.h"
}

//#############################
//DEFINIZIONI VARIABILI GLOBALI
//#############################
		volatile	unsigned char	isr_encFlag		= ENC_IDLE;
					unsigned char	enc_switchCnt	= 0;
					unsigned char	wtdgCnt			= 0;
					unsigned char	toggle			= 0;
//#############################




void setup()
{

	/* add setup code here */
	Serial.begin(115200);
	IO_Conf();
	Timer1_Conf();
}

void loop()
{

	/* add main program code here */
	if ((isr_encFlag & ENC_SW_MASK) == (ENC_SW_PENDING + ENC_SW_SHORT)) {
		if (toggle) {
			toggle = 0;
			LED_LO;
		}
		else {
			toggle = 1;
			LED_HI;
		}
		noInterrupts();
		isr_encFlag &= ~(ENC_SW_MASK);  //***FIRST BREAKPOINT HERE***
		interrupts();
	}
}


//############################################ROUTINE DI INTERRUPT (ISR)##############################################


//##########################
//TIMER1 OVERFLOW (5Ms TICK)
//##########################
ISR(TIMER1_COMPA_vect)
{

	DEBUG_HI;
	//----------------------------
	//Controllo retrigger watchdog
	//----------------------------
	if(++wtdgCnt == CNT_WTDG) {
		wtdgCnt = 0;
//		__watchdog_reset();
	}
	//----------------------
	//Encoder switch management
	//Debounce control
	//----------------------
	if (ENC_SW_SENSE) {
		if (enc_switchCnt <= CNT_SW_LONG) {
			if (enc_switchCnt == CNT_SW_SHORT) {
				isr_encFlag &= ~(ENC_SW_MASK);
				isr_encFlag |= (ENC_SW_SHORT + ENC_SW_WAITREL);
			}
			if (enc_switchCnt == CNT_SW_LONG) {
				isr_encFlag &= ~(ENC_SW_MASK);
				isr_encFlag |= (ENC_SW_PENDING + ENC_SW_LONG);
			}
			enc_switchCnt++;
		}
	}
	else {
		enc_switchCnt = 0;
		if (isr_encFlag & ENC_SW_WAITREL) {
			isr_encFlag &= ~(ENC_SW_WAITREL);
			isr_encFlag |= (ENC_SW_PENDING); //***SECOND BREAKPOINT HERE***
		}
	}
	DEBUG_LO;
}

 



Zip file of the project is included.
Any idea to solve the problem or to explain the behaviour?
Thanks in advance and regards.

« Last Edit: Oct 30th, 2015 at 11:48pm by Robydid »  

Please Register or Login to the Forum to see File Attachments
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12191
Location: United Kingdom
Joined: Apr 10th, 2010
Re: unexpected program stop when debugging
Reply #1 - Oct 31st, 2015 at 12:01am
Print Post  
Thanks for the detailed info.

The problem happens with the 2nd break-point because it is inside an isr.

The first thing to ensure is that you switch off the debugger throttling which is a property property called "Throttle Enabled". The throttle usual applies just to trace points which don't pause the program so can stream huge numbers of messages but it can add delays() so best switched off.

The throttle ensures that when less experienced users put breakpoints in the loop the debug messages are not sent to windows at 16 mhz. To achieve this visual micro uses a delay() and keeps track of the last breakpoint millis() ensuring no less than 80 milliseconds has passed before allowing the mcu to continue. 

When you switch it off you will need to ensure that, depending on pc speed and debugger watch data, messages are limited to 10hz otherwise the pc won't process the messages fast enough and the debug display might fall behind "realtime". 

You probably know you can use the hit counter which defaults to millis() or conditional breakpoints or you can do as you have done as long as the "if" condition won't be met to frequently. Your if statement as far as I can tell is this  

Code
Select All
if ((isr_encFlag & ENC_SW_MASK) == (ENC_SW_PENDING + ENC_SW_SHORT) 



With the Throttle off I am keen to know if things work. Other users have reported it does but the documentation currently says it isn't supported which I would like to be able to change.

If you still have a problem without the Throttle then please switch on "tools>options>visual micro>compiler>show build folder". Make a build then ctrl+click the shortcut that appears in the output, zip and email the output to info[at]visualmicro.com

Thanks

« Last Edit: Oct 31st, 2015 at 3:19pm by Tim@Visual Micro »  
Back to top
IP Logged
 
Robydid
Newbies
*
Offline


Posts: 4
Location: Italy
Joined: Oct 30th, 2015
Re: unexpected program stop when debugging
Reply #2 - Oct 31st, 2015 at 10:54am
Print Post  
Thanks a lot for the info. I recognised that I did not give you all the details. Here we are...
I used for both breakpoints basically the same conditions i.e. hit count = 1 (Counters is selected for Hit Counters parameter).
The breakpoint in the isr routine (tick timer of 5mS) will always be the first breakpoint processed and the breakpoint in the main loop wil react consequently.
I have isolated a single occurrency for each breakpoint and pushing a button starts the breakpoint's capture.
As I wrote in the previous post when one of the two breakpoints is not active everything is fine;
when both are active the second breakpoint processed (it should be always the breakpoint in the main loop) stops the program unexpectedly.
Please find pictures for the debugger configuration and breakpoints conditions (same for both).
Meanwhile I am going to play with throttle settigs to see the differences. Thanks for the explanation; I saw that parameter but I did not understand completely its meaning before.
I will come to you with some results soon.
Regards.
  

Please Register or Login to the Forum to see File Attachments
Back to top
 
IP Logged
 
Robydid
Newbies
*
Offline


Posts: 4
Location: Italy
Joined: Oct 30th, 2015
Re: unexpected program stop when debugging
Reply #3 - Oct 31st, 2015 at 11:55am
Print Post  
Hi again,
I have played switching only the parameter "Throttle_Enabled" between false and true (default).
Well I can confirm that with throttle just false the two breakpoints are processed and I get a result without any program hangs.
Please find the two picture of wahat happens when I push the button in both cases.
when the throttle is enabled the program stucks and I see nothing on the com window (none of the breakpoints process seems to be returned). When the Throttle is disabled I see the expected behaviour i.e. program still running and both breakpoints actions returned...
Still it is not completely clear to me if I can manage breakpoints occurring too close or not and I will do some test concerning this.
As far as I expect VM debugger should be able to manage such a situation if the user avoid that too many breakpoints are occuurring too close.
In my case I have only two hits but are pretty close together. I think it is not a big problem if VM place a small hidden delay to manage the capture; it would be a mess if VM would not be able to capture close events although the total number of breakpoints hits is kept limited by breakpoint conditions.
Thanks and regards.
  

Please Register or Login to the Forum to see File Attachments
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12191
Location: United Kingdom
Joined: Apr 10th, 2010
Re: unexpected program stop when debugging
Reply #4 - Oct 31st, 2015 at 3:08pm
Print Post  
Great.

Yes the debugger can handle lots of breakpoints all together. 

If the breakpoints are tracepoints and hundreds are being set then my comment about the pc becoming swamped might apply.

As you know visual micro is only adding standard arduino code to make the debugger work so any problem should always be easily identifiable. It's not a very clever system and you can easily see what it is doing in the .cpp files(s) in the build output folder.
« Last Edit: Oct 31st, 2015 at 3:45pm by Tim@Visual Micro »  
Back to top
IP Logged
 
Page Index Toggle Pages: 1
Send TopicPrint