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