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
Locked Topic Board won't start or work properly with debug build (SOLVED) (Read 13253 times)
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Board won't start or work properly with debug build (SOLVED)
Nov 7th, 2015 at 1:07am
 
I've found on my BIG application, I get a hang during initialization when in Debug mode.  The code works perfectly in Release mode, and the debugger works fine in simpler applications.  So, I'm guessing my code and the debugger are somehow stomping on each other.  The code is very heavily interrupt-driven, and does use one of the Due timers, if that matters.

Any idea where to look for a conflict?

Regards,
Ray L.
« Last Edit: Nov 14th, 2015 at 2:15am by Tim@Visual Micro »  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12191
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Can Debugger Interfere With User Code?
Reply #1 - Nov 7th, 2015 at 1:16am
 
Hi Ray,

1) The debugger uses Serial, so one question is if your project supports that.

2) You can use a different serial port for debug if that avoids a timer clash or you can use softwareSerial on digital pins

3) You should ensure that project property ThrottleEnabled=False which will prevent Visual Micro from smoothing debug packets with the delay method.
  
Back to top
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Can Debugger Interfere With User Code?
Reply #2 - Nov 7th, 2015 at 1:59am
 
Tim@Visual Micro wrote on Nov 7th, 2015 at 1:16am:
Hi Ray,

1) The debugger uses Serial, so one question is if your project supports that.

2) You can use a different serial port for debug if that avoids a timer clash or you can use softwareSerial on digital pins

3) You should ensure that project property ThrottleEnabled=False which will prevent Visual Micro from smoothing debug packets with the delay method.


1) Yes, I do use serial, lots of serial.  My primary port is the Programming port, used for downloading, and as the "Console" port.  The Native port is used as a second "console" port, albeit with a different set of commands.  Three hardware serial ports are also available, though I don't currently use them in debugging.  I am pumping quite a lot of data through the Programming port at times, as it is my primary debugging interface, and I have a messaging infrastructure that allows me to do Debug printf's from virtually anywhere in the code, including from within ISRs.

2) "Timer clash"?  Are you doing serial output based on a timer?  I use the Arduino Serial device, using its built-in, interrupt-driven buffering.

3) I will try turning off throttling.

Regards,
Ray L.
  
Back to top
 
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Can Debugger Interfere With User Code?
Reply #3 - Nov 7th, 2015 at 2:22am
 
One step forward, one step backward.  The good news is: turning off throttling gets me past the hang, and the app works as it should.  The bad news is:  I can't get it to execute a breakpoint.

Regards,
Ray L.
« Last Edit: Nov 7th, 2015 at 2:22am by RayLivingston »  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12191
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Can Debugger Interfere With User Code?
Reply #4 - Nov 7th, 2015 at 1:23pm
 
Would you mind restarting VS and not opening a project. 

Then open the serial terminal and sending me the output up until the breakpoint is hit. You will see the breakpoint(s) in the serial terminal. This would be breapoint 1 without any var data:-
VMDPE_1_VMDPE

If you see the breakpoint please post 3 lines of text. The line before, the VMDPE line and the line after.

It might be that your own serial is preventing Visual Micro from seeing the packet. Your prints should end with a line terminator for best use.

It is also an idea to ensure you understand that breakpoints are inserted at the end of a line, if a conditional code line then often they will be inside the condition. You can see this in the Exact location of a breakpoint section in this doc http://www.visualmicro.com/page/User-Guide.aspx?doc=Debugging.html

Because you are making such heavy use of the serial I think it would be much cleaner to use an alternative port if possible. The project property RemotePort can contain Serial2 or Serial3 etc, and LocalPort should contain whatever pc COMn port that represents.
« Last Edit: Nov 7th, 2015 at 1:24pm by Tim@Visual Micro »  
Back to top
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Can Debugger Interfere With User Code?
Reply #5 - Nov 7th, 2015 at 9:58pm
 
Tim,

I never hit a breakpoint....  And I never see VMDPE_1_VMDPE.  In release mode, everything works fine.  In Debug mode, it hangs when it reaches the first breakpoint.

Code (C++)
Select All
	// Read Config from EEROM
	pConsole->printf("Reading Configuration from EEROM...\n");
	MasterConfig = new ATCConfig(eerom_i2c_if, eerom_i2c_addr, eerom_i2c_wp, VERSION_MAJOR, VERSION_MINOR, VERSION_FLAGS);
	if (!MasterConfig->retrieveConfig())
	{
 



The breakpoint is set on the line with the printf.  The console prints "Re" then hangs.

I have verified the port/baud settings are correct at both ends:  COM4/115200 and Serial/115200.

Regards,
Ray L.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12191
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Can Debugger Interfere With User Code?
Reply #6 - Nov 7th, 2015 at 10:05pm
 
Hi Ray,

fyi: If you are debugging on the standard upload port you don't have to set the settings for localport and remoteport

I think the problem is the serial debugger doesn't work well to debug a printf debug statement.

I think it's one or the other otherwise you need a clean serial port for debug.

The visual micro code is a series of bog standard Serial.print() commands followed by a Serial.println() so that's what isn't being sent from the arduino
  
Back to top
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Can Debugger Interfere With User Code?
Reply #7 - Nov 7th, 2015 at 11:44pm
 
Tim,

I've found what seems to me a clear bug in VM:

  I decided to play with a small test program, instead of my huge, hulking monster application.  But I'm getting some truly bizarre errors.  First, here is the program (just something I used a while back to resolve a problem I was having using variable arguments).

First, I set HitCounter to Counter rather than millseconds.

Code (C++)
Select All
#include <Arduino.h>
#include <stdio.h>
#include <stdarg.h>

/**************************************************
 * DebugMsg()
 *************************************************/
void DebugMsg(const char *fmt, ...)
{
		char s[256];
		__gnuc_va_list  args;

		va_start (args, fmt);
		vsprintf (s, fmt, args);
		Serial.print(s);
		va_end (args);
}

void setup()
{
	Serial.begin(115200);

}

int cnt = 0;
void loop()
{
	cnt++;
	DebugMsg("Hello, %s %d %c %f\n", "world", 42, 'X', 1.2345);
	delay(100);
}
 



If I set a single breakpoint on the DebugMsg line in loop, it works fine.  I then set a condition of "cnt > 0", and it also works fine.  But, I then set HitCount to anything BUT "always", I get these compiler errors:

Quote:

Compiling debug version of 'BlivetSketch' for 'Arduino Due (Programming Port)'
Build folder: due_x_dbg
BlivetSketch.ino:1:107: error: stray '#' in program
:unsigned long __VisualMicro_DEBUG_1_HITCOUNTER__ = 0L;bool __VisualMicro_DEBUG_1_HITCOUNTER___COMPLETE = 0#include "arduino.h"
BlivetSketch.ino:6:28: error: stray '#' in program
:*[VM_DEBUG_HEADERS_END]*\#include <Arduino.h>
BlivetSketch.ino:1:108: error: expected ',' or ';' before 'include
:unsigned long __VisualMicro_DEBUG_1_HITCOUNTER__ = 0L;bool __VisualMicro_DEBUG_1_HITCOUNTER___COMPLETE = 0#include "arduino.h"
BlivetSketch.ino:6:29: error: 'include' does not name a type
:*[VM_DEBUG_HEADERS_END]*\#include <Arduino.h>
BlivetSketch.ino:In function 'void loop()
BlivetSketch.ino:32:58: error: 'DebugMsg' was not declared in this scope
CheesyebugMsg("Hello, %s %d %c %f\n", "world", 42, 'X', 1.2345);if (cnt > 0) {__VisualMicro_DEBUG_1_HITCOUNTER__ +=1;if ((__VisualMicro_DEBUG_1_HITCOUNTER__==5)  ) { __VisualMicro_DEBUG_1_HITCOUNTER__=0L;
    debugger: The error shown above might be caused by invalid breakpoint syntax?
Error compiling


If I insert a blank line as the very first line of the file, I get:

Quote:

Compiling debug version of 'BlivetSketch' for 'Arduino Due (Programming Port)'
Build folder: due_x_dbg
BlivetSketch.ino:1:107: error: stray '#' in program
:unsigned long __VisualMicro_DEBUG_1_HITCOUNTER__ = 0L;bool __VisualMicro_DEBUG_1_HITCOUNTER___COMPLETE = 0#include "arduino.h"
BlivetSketch.ino:1:108: error: expected ',' or ';' before 'include
:unsigned long __VisualMicro_DEBUG_1_HITCOUNTER__ = 0L;bool __VisualMicro_DEBUG_1_HITCOUNTER___COMPLETE = 0#include "arduino.h"
Error compiling


Set HitCounters back to milliseconds, and all these errors go away.

Regards,
Ray L.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12191
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Can Debugger Interfere With User Code?
Reply #8 - Nov 8th, 2015 at 4:49pm
 
Thanks alot. Yes that had gone wrong with a recent update.

It's fixed in the release due later today.

Thanks
  
Back to top
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12191
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Can Debugger Interfere With User Code?
Reply #9 - Nov 9th, 2015 at 1:49am
 
Hi Ray,

There is a new release that should solve the main things you have raised.

1) Compiler cache of local sketch files
2) Fix debugger bug
3) Upload progress during upload instead of after

It's available in VS via "tools>extensions and updates" or the usual the downloads page

I hope it does the job. Thanks again.
« Last Edit: Nov 9th, 2015 at 2:01am by Tim@Visual Micro »  
Back to top
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Can Debugger Interfere With User Code?
Reply #10 - Nov 9th, 2015 at 2:53am
 
Tim,

The update has fixed the problem with Hit Counters breaking the compile, and I now get very nice progress updates during the download - a BIG improvement.

Unfortunately, I can't test whether debugging works with my monster app right now, as I have it all ripped apart for some major updates.  I should be able to test again sometime tomorrow.

Thanks much for the quick fixes!

Regards,
Ray L.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12191
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Can Debugger Interfere With User Code?
Reply #11 - Nov 9th, 2015 at 3:00am
 
Okay thanks for the update. I have just published an minor sp2 tweak. I am not sure if the new local sources cache was working in the earlier update.

If it's working the compile of your files will be significantly faster and you will see verbose messages like this when files are skipped.

Code (C++)
Select All
Using previously compiled file: C:\.....\Arduino\Builds\Sketch36\uno\mycode.cpp.o 



Thanks for the quick update letting me know the version works.

Best of luck, hope the compiles are super fast Smiley
« Last Edit: Nov 9th, 2015 at 3:03am by Tim@Visual Micro »  
Back to top
IP Logged
 
RayLivingston
Full Member
***
Offline


Posts: 158
Location: California
Joined: Nov 24th, 2012
Re: Can Debugger Interfere With User Code?
Reply #12 - Nov 9th, 2015 at 6:28am
 
Tim,

Compile and download are now working very nicely, but still no joy with debugging my big application.  It still skips right over all breakpoints, like its in release mode.

Regards,
Ray L.
  
Back to top
 
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12191
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Can Debugger Interfere With User Code?
Reply #13 - Nov 9th, 2015 at 4:07pm
 
Thanks Ray,

I found that if I place a breakpoint on a line of code that calls your debug printf function the serial.print messages that visual micro expects are not sent.

If I placed a breakpoint before or after your debug() command (even on empty lines) then they worked fine.

I'll be looking into it shortly!
  
Back to top
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12191
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Can Debugger Interfere With User Code?
Reply #14 - Nov 9th, 2015 at 4:22pm
 
Oh, I forgot to change my breakpoint hit count from "equal to" to "multiple of" so a breakpoint on the debugMsg() line in your example below worked okay for me.

Can you zip and email the cpp files from your temp build folder (inc sub folders) after debug compile.

Also send the files from the /__vm folder below your sketch.

Thanks
« Last Edit: Nov 9th, 2015 at 4:24pm by Tim@Visual Micro »  
Back to top
IP Logged
 
Tim@Visual Micro
Administrator
*****
Offline


Posts: 12191
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Board won't start or work properly with debug build (SOLVED)
Reply #15 - Nov 14th, 2015 at 2:01am
 
Ray great to hear you have the debugger working. Thanks for sending the useful info that helped to find the issue.

For anyone else who find the debugger is not working at all this might help:-

We found that if the setup() and loop() methods are not in the [sketch_name].ino source code then the debugger fails to work. There will be an update during coming weeks to support this configuration but until then please ensure that the setup() and loop() are located in the master sketch .ino.

Also interesting to note that the debugger uses serial ports or softwareSerial as a transport mechanism. This means it won't work with time critical code can not be used in code that overrides the interrupts in a way that interferes with the transport. Switching off the ThrottleEnabled project property will help inside ISR code but this type of usage can not be guaranteed. Sorry

Thanks again Ray
« Last Edit: Nov 22nd, 2015 at 7:12pm by Tim@Visual Micro »  
Back to top
IP Logged
 
Page Index Toggle Pages: 1
Send TopicPrint