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 Breakpoints highly unreliable, no guidance as to why. (Read 2354 times)
MilanS
Newbies
*
Offline


Posts: 3
Joined: Aug 24th, 2014
Breakpoints highly unreliable, no guidance as to why.
Aug 24th, 2014 at 11:04pm
Print Post  
Hi,

im frustrated with the debugging, the only reason why i bought visual micro yesterday - setting breakpoints. It only seems to work sometimes. Reading forum, there seems to be subtlety as to why, but the plugin itself never tells and it seems difficult to know why certain breakpoint wont hit and some other will.

Im attaching a project that simply uses HR-04 sonar sensor and notice how the breakpoints there wont work. Serial.print also never shows up in the serial monitor.

Im using Visual Studio 2012.

Why isnt it working?

Thanks!
Milan
  

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


Posts: 12188
Location: United Kingdom
Joined: Apr 10th, 2010
Re: Breakpoints highly unreliable, no guidance as to why.
Reply #1 - Aug 25th, 2014 at 1:09am
Print Post  
Hi,

Sorry you have some frustrations. The 30 day trials are designed to ensure you have a working system before buying  Smiley

Some info that should help. I'll bul

1) serial.print() will only show up when you add a \n or println(). The monitor works this way if it detects debug will be required.

2) The project you attached does not have any breakpoints set. It would be useful to see where you are putting them. The injected serial debugger works different to other debuggers. The debug command is injected after the current line which in the case of an "IF" it will be placed inside the "IF" (see docs for more info)

3) When debug starts. Depending on pc speed, if a breakpoint is placed in the setup() or early on it is possible for the arduino to start before the pc is ready. In this case the arduino will break but the pc won't know. This can be avoided easily but if you suspect this has happened use the serial monitor to send the 'c' command.

4) I notice you are using a lot of serial and also sharing the serial port with the debugger. The arduino has a very small serial buffer, if too much serial is generated at the same time then it an be possible for the buffer to wrap destroying the data that has not yet been sent. This would cause breakpoint packets to be ignored and can be complicated by serial.print() without /n. You printf seem to have the /n and if this is a huge problem you would see the "part" packets appearing in the monitor. So this point is probably just something to bear in mind and not applicable. You can use a different port for debug or the softwareSerial debug option which gives a dedicated debug channel.

Hopefully the problem is 2) above but more info/example would be useful. The breakpoints should be and are generally reliable.

Thanks
  
Back to top
IP Logged
 
Page Index Toggle Pages: 1
Send TopicPrint