I've been using the plug-in without the debugger for several weeks with no problems whatsoever.  Today I installed the debugger, and, when (Micro Debug) is set to "Full", I get the errors below - it appears the vectors are being multiply defined.  If I turn (Micro Debug) off, all is fine.  Any ideas?

Regards,
Ray L.


Compiling 'SkyNet' for 'Arduino Mega 2560 or Mega ADK'
Binary sketch size: 11648 bytes (of a 258048 byte maximum) (1.046875 secs)
Compiling debug version of 'SkyNet' for 'Arduino Mega 2560 or Mega ADK'
core.a(HardwareSerial.cpp.o)* : : In function `__vector_25':
HardwareSerial.cpp : multiple definition of `__vector_25'
SkyNet.cpp.o : :/HAL_Arduino_Code.h:372: first defined here
ld.exe : : Disabling relaxation: it will not work with multiple definitions
core.a(HardwareSerial.cpp.o)* : : In function `__vector_36':
HardwareSerial.cpp : multiple definition of `__vector_36'
SkyNet.cpp.o : :/HAL_Arduino_Code.h:383: first defined here
core.a(HardwareSerial.cpp.o)* : : In function `__vector_51':
HardwareSerial.cpp : multiple definition of `__vector_51'
SkyNet.cpp.o : :/HAL_Arduino_Code.h:394: first defined here
core.a(HardwareSerial.cpp.o)* : : In function `__vector_26':
HardwareSerial.cpp : multiple definition of `__vector_26'
SkyNet.cpp.o : :/HAL_Arduino_Code.h:302: first defined here
core.a(HardwareSerial.cpp.o)* : : In function `__vector_37':
HardwareSerial.cpp : multiple definition of `__vector_37'
SkyNet.cpp.o : :/HAL_Arduino_Code.h:313: first defined here
core.a(HardwareSerial.cpp.o)* : : In function `__vector_52':
HardwareSerial.cpp : multiple definition of `__vector_52'
SkyNet.cpp.o : :/HAL_Arduino_Code.h:324: first defined here
avr-objcopy* : : 'C:\Documents and Settings\RayL\Local Settings\Application Data\VMicro\Arduino\Builds\SkyNet\mega2560\SkyNet.elf': No such file
avr-objcopy* : : 'C:\Documents and Settings\RayL\Local Settings\Application Data\VMicro\Arduino\Builds\SkyNet\mega2560\SkyNet.elf': No such file
Couldn't determine program size: 

Hi, okay this might be a couple of things. First off, install of the debugger doesn't alter the way vm works when it is switched off (not set to Full) so we are possibly looking at two problems.

1)

Quote:


When you installed the debugger did you also upgrade your visual micro installation to the latest release? What version of vm is installed tools>options>visual micro>version? Based on your answers I will have more info.

2) 

Quote:


This looks like you are overriding the normal Arduino HardwareSerial system. The debugger currently supports HardwareSerial, UsbSerial (leonardo types), SoftwareSerial and FastSerial. By default it will attempt to use HardwareSerial which would cause this error if you are creating your own "Serial" object.

The best thing to do for now would be to override the FastSerial option as follows:-  
1) In the project debug properties set the RemoteTransport to "FastSerial"

2) Change the FastSerial.h and FastSerial references in the "VM_DBG.h" and "VM_DBG.cpp" to your own serial classes  such as "HAL_Arduino_Code.h" 

The only code you should change in the .cpp and .h will be contained within a test for VM_DEBUGGER_TYPE_FASTSERIAL. Do not change the #if just change the code within.

#if defined(VM_DEBUGGER_TYPE) && VM_DEBUGGER_TYPE == VM_DEBUGGER_TYPE_FASTSERIAL 

Tip: Make a backup of your changes because the vm installer will overwrite the following files when you next upgrade, the .cpp and .h files can be found below the vm program folder. Example: "C:\Program Files (x86)\Visual Micro\Visual Micro for Arduino\Micro Platforms\Arduino\Templates\Hardware\Debuggers\VM_DBG"

If you are unsure of where vm is installed you will find the location in Tools>Options>Visual Micro>Version>Assembly

Tim,

In doing some reading on Arduino Hardware serial, it appears (unless I'm reading out of date posts) that there are a surprising number of people complaining about some pretty significant issues in the low-level code - sitting in spin loops while transmitting, consuming large amounts of memory for serial buffers, even when those ports are not used.  Do you now if these issues have been fixed in current libraries?   

Really stupid question time:  If I simply use serial.begin, serial.available, serial.read and serial.write, am I getting interrupt-drive I/O?  It would be trivial for me to re-write my code around this interface if it will get the job done and resolve the current conflicts.

Regards,
Ray L.

Tim,

My installed version appears to be 1.1211.04, even though I DID install 1201.24 before installing the debugger.  Obviously, I had the newer version from my initial install a week or so back.  Is this a problem?

I do have an FTDI USB serial cable - it's what I'm using to talk, and program, to the board (Mega2560), but I'll try porting to the Arduino serial drivers first, and see how that goes.  Shouldn't take long - I'll let you know what happens.

Thanks!

Regards,
Ray L.

Well, it gets wierder....  I replaced my low-level code with Serial.begin, serial.read, serial.write, and serial.available.  I can't get *anything* to come out!  Even when I put:

serial.begin(57600);
serial.println("Hello, world");

in setup(), nothing comes out.  How is that possible?  Change one define to put my driver back in and it works perfectly.

I'll try another board a bit later.  I don't have one here right now.

Regards,
Ray L.

Tim,

This is very peculiar....  I cannot for the life of me get the Serial class to actually work.  Even running a bare-minimum sketch that does a serial.begin and serial.println, nothing comes out on the terminal.  It did work before I installed the debugger....

Regards,
Ray L.

Is the serial monitor set to 57600?

Is the DTR checkbox on the serial monitor (make the window wider to see it) checked? 

Adding serial.print to the setup only happens once when the arduino starts so it is easily missed. The DTR will force the arduino to reboot when the serial monitor opens so you should then see the message.

It is better to add serial.print to the loop when testing

Oh, does your terminal program set the dtr? If not the arduino will start and send the message before your program can connect to the port.

As a test I would move the serial.println("Hello World") from the setup() to the loop(). You should then see hundreds of "Hello World" messages in your terminal program.

Ray, I'm getting a bit confused

I thought you reported this

Quote:


But in your last post you said this

Quote:


So is the normal arduino serial working okay now? If so then we are just discussion multiple interrupts?

So let's leave the debugger disabled for the time being.

Can you use Serial2.println("Hello World") in your own sketch combined with your own interrupt handling of Serial?

Not sure why your terminal program isn't seeing any data. The dtr only affects the arduino when the terminal program open the serial port. It causes the arduino to reboot so that the setup() runs once. After the reboot the dtr has no affect unless it is toggled.

Good to hear you found a solution to detect "done transmit". That sounds like a good halfway house between arduino and avr! 

Obviously you WILL need to run the debugger on a different port to the one you are testing for "transmit complete".

Please keep in mind that the debugger will block under various circumstances. Some of which can be disabled. I haven't investigated the arduino non-blocking transmit for debugger use. Non-blocking will have implications for how many TracePoint messages could be transmitted by the arduino without overflowing the transmit buffer....

Summary

The debugger is not recommended for time critical applications. There are various configuration properties that do allow use in time critical projects but these considerations require a certain amount of careful thought. 

For example the placement of breakpoints in places of least impact to time critical functions, applying conditions to breakpoints to ensure execution is limited to major events and/or exceptions, using the "Hit Counter" system to reduce the frequency

Tim,

Is the debugger using Serial?  It appears to me Serial grabs all available ports, even if you're using only one.  If so, could I just cobble HardwareSerial.cpp to only use a single port when using the debugger?

Regards,
Ray L.

Tim,

Ah, ok!  I set Transport to Software Serial, and it's now compiling and loading, so I think I should be OK - just have to get my code off that serial port.

Regards,
Ray L.

Tim,

I'm trying to get Software Serial working, and I think I'm close, but having different compile problems.  I've set:

Local Port: COM7
Local Speed: 115200

Remote Rx Pin: 10
Remote Tx Pin: 11
Remote Port: Serial
Remote Speed: 115200
Remote Transport: Software Serial

I have Pins 10 & 11 connected to the RS232 level converter, which is plugged into the USB Serial cable, which Windows sees as COM7.

The compile errors I get are:

Compiling 'SkyNet' for 'Arduino Mega 2560 or Mega ADK'
Binary sketch size: 13146 bytes (of a 258048 byte maximum) (1.234375 secs)
Compiling debug version of 'SkyNet' for 'Arduino Mega 2560 or Mega ADK'
SkyNet.ino : : In function 'void setup()':
SkyNet.ino : begin(HardwareSerial*, long int)'
VM_DBG.h : begin(SoftwareSerial*)
VM_DBG.h : begin(SoftwareSerial*, long int)
Error compiling

Regards,
Ray L

Tim,

Clearing the Remote Port property now has it compiling and loading, but when I set a breakpoint, the second monitor window just shows: "Waiting for debug breakpoint data".  If I don't set a breakpoint, the application does run.  If I do set a breakpoint, it appears to stop at the breakpoint, but the debugger never shows anything, and the "Waiting" message never goes away.   Even odder, the Monitor window now refuses to display the output from my program, though my custom terminal program, displays everything just fine.  That makes no sense at all to me, since they are simply monitoring a COM port on the PC!

I will e-mail my sketch shortly.

Regards,
Ray L.

Tim,

Some progress - I've gotten SoftwareSerial to work, using a simple test program.  I was confused about pin numbers....  Now trying to get the debugger to work with the LED blinking program.  If I set a breakpoint in loop(), and specify "print a message and continue execution", the printouts do come out in the Output window.  So, obviously the board and PC are talking.  At one point, it was also displaying something each pass of loop(), but that stopped - no idea why.  But it I set a regular breakpoint, nothing happens, other than periodically printing "12:53:59.968 BlivetSketch.ino, line 14" in the output window.  The "expressions on COM7" window never shows anything other than "Waiting for debug breakpoint data" in blue.

I also noticed some things in VS seem to have gotten whacked in installing the debugger, which may be the whole problem here.  The Project menu now has two new items "Upload last Arduino build" and "Show all Arduino file", but there are DOZENS of each in there.  I have NO Watch window, and it doesn't shows up anywhere in the View menu.

Regards,
Ray L.

Tim,

resetaddin does get rid of the extra menu items, leaving only one set.  But, if I close then re-open VS, then I have two copies.  Close and re-open again, and I now have three copies.  And so on...

Regards,
Ray L.

Tim,

Actually, VisualMicro is the ONLY add-on I have installed:

Microsoft Visual Studio 2008
Version 9.0.30729.1 SP
Microsoft .NET Framework
Version 3.5 SP1

Installed Edition: Standard

Microsoft Visual Basic 2008   91851-136-1197172-60481
Microsoft Visual Basic 2008

Microsoft Visual C# 2008   91851-136-1197172-60481
Microsoft Visual C# 2008

Microsoft Visual C++ 2008   91851-136-1197172-60481
Microsoft Visual C++ 2008

Microsoft Visual Web Developer 2008   91851-136-1197172-60481
Microsoft Visual Web Developer 2008

Hotfix for Microsoft Visual Studio 2008 Standard Edition - ENU (KB2538241)   KB2538241

Hotfix for Microsoft Visual Studio 2008 Standard Edition - ENU (KB944899)   KB944899

Hotfix for Microsoft Visual Studio 2008 Standard Edition - ENU (KB945282)   KB945282

Hotfix for Microsoft Visual Studio 2008 Standard Edition - ENU (KB946040)   KB946040

Hotfix for Microsoft Visual Studio 2008 Standard Edition - ENU (KB946308)   KB946308

Hotfix for Microsoft Visual Studio 2008 Standard Edition - ENU (KB946344)   KB946344

Hotfix for Microsoft Visual Studio 2008 Standard Edition - ENU (KB946581)   KB946581

Hotfix for Microsoft Visual Studio 2008 Standard Edition - ENU (KB947173)   KB947173

Hotfix for Microsoft Visual Studio 2008 Standard Edition - ENU (KB947540)   KB947540

Hotfix for Microsoft Visual Studio 2008 Standard Edition - ENU (KB947789)   KB947789

Hotfix for Microsoft Visual Studio 2008 Standard Edition - ENU (KB948127)   KB948127

Hotfix for Microsoft Visual Studio 2008 Standard Edition - ENU (KB953256)   KB953256

Hotfix for Microsoft Visual Studio 2008 Standard Edition - ENU (KB971091)   KB971091

Microsoft Visual Studio 2008 Standard Edition - ENU Service Pack 1 (KB945140)   KB945140

Microsoft Visual Studio 2008 Standard Edition - ENU Service Pack 1 (KB947888)   KB947888

Microsoft Visual Studio 2008 Standard Edition - ENU Service Pack 1 (KB948484)   KB948484

Security Update for Microsoft Visual Studio 2008 Standard Edition - ENU (KB2251487)   KB2251487

Security Update for Microsoft Visual Studio 2008 Standard Edition - ENU (KB2669970)   KB2669970

Security Update for Microsoft Visual Studio 2008 Standard Edition - ENU (KB972222)   KB972222

Update for Microsoft Visual Studio 2008 Standard Edition - ENU (KB956453)   KB956453

Update for Microsoft Visual Studio 2008 Standard Edition - ENU (KB967143)   KB967143

Update for Microsoft Visual Studio 2008 Standard Edition - ENU (KB972221)   KB972221

Visual Micro Arduino
Copyright Visual Micro 2009

Regards,
Ray L.

Tim,

There is no Tools->Options->Extension Manager in my VS.  I can't find Extension Manager anywhere....

Regards,
Ray L.

Tim,

I guess I can live with the menu issues, for now.  But, back to the original problem, still no go.  I Enabled Break/Pause, but when it hits the breakpoiint, a message is printed indicating execution is paused, but the message specified in "When hit" does not display, nor does the Expression window ever appear.  The "Waiting for debug breakpoint data" also never goes away, and nothing is ever displayed in that window.  There appears to be no way to continue execution from that point.  The breakpoint source line does highlight when the breakpoint is hit.  This is all running a simple blink application, using hardware serial.

Would it be worthwhile to un-install the plug-in and debugger, and try again?

Regards,
Ray L.

Tim,

What messages I get, come out in the VS Output window.  There are two additional windows, both apparently tied to COM7 (the serial port connected to the Arduino serial port), one of which says only "Port Open", and the other, which I just (stupidly) realized *is* the expression window, which has never shown anything but "Waiting for debug breakpoint data".

When I turn off Break/Trace, I get nothing at all in the output window after the program finishes loading.  The two COM7 windows show the same thing as always - basically nothing.

VS is also now throwing an error when I exit - I get the error dialog asking if I want to send an error report to Microsoft.

Regards,
Ray L.

I un-installed VisualMicro and the debugger, re-installed the latest VisualMicro, and confirmed it worked properly, then re-installed the beta debugger, and VS is now back to crashing on exit, and the debugger is not working.  So, whatever is wrong seems tied tot he debugger, not to Visual Micro.

Regards,
Ray L.

Tim,

Since last night, for reasons I can't explain, because I didn't change anything, it's behaving differently, and *almost* working.  I have now, several times, run the program, and it has stopped at the breakpoint, properly displayed the messages in the output window, and properly displayed the variables in the expressions window.  The odd thing is, right now, it doesn't matter whether I have Break/Pause checked or not - it ALWAYS stops at the breakpoint, even though the specified breakpoint action is Print a Message then Continue Execution.  Hitting F5 at this point always results in re-compiling, and re-starting the program, so it appears the debugger for some reason does not think it stopped at a breakpoint.

Regards,
Ray L.

Hi Ray, 

What LocalSpeed are you using?

Can you upload a "Release" version and then a "Debug" version to see if this allows it to work without break/pause.

Thanks

Tim,

I did do another resetaddin, which cleared the duplicates, but they still come back, adding one each time I start VS.  I can live with that.  It does appear then that attempting to install an old plug-in over a newer one is a bad idea, as I don't see how else I could've ended up with two of them showing up in the Add/Remove Programs list.

But, the important thing is all seems to be working well now, and I'm looking forward to getting some good use out of the debugger!

Regards,
Ray L.

Tim,

The initial install was only about a week ago, and was the latest version (same one I have installed now).  The over-install was a slightly earlier version - the minimum recommended for use with the "Stable" release of the debugger.  When I did the second install, it did offer to "repair" the installation, but obviously what it did was not really a repair....

I always run with Admin rights, but I'll try logging in as Admin, and see if that does anything positive.

Regards,
Ray L.