It's Saturday, and I work because development is late...

On top of that, I get some weird, and unwanted,  gltches  .

At the begging of loop(), and only once, I write something to Serial (the port used to upload the program). After a re-upload of the program, I don't get on the Serial monitor what I should read. Sometimes, closing and restarting the Serial monitor is enough for my friend (?) to display what I sent...

And closing and restarting the Serial monitor resets the board  .

EDIT

One more glitch. When the Serial monitor is displayed, and I upload With Debug:

• I am not told a Debug Session is already running... and the added breakpoints are not executed
• To get the message that a Debug Session is already running... I need to first close the Serial Monitor, and then the new breakpoints do their job.

Just what is going on ??? Are Sherlock and Dr Watson free to come up to my place ? By the way, this new Sherlock TV show is quite a great show  .

AtmelStudio: 6.1   VisualMicro: 1.1401.26

Thanks

Quote:

Some more info about my environment:

• Uploading of programs is through Serial
• The debugger is set to use Serial also
• I have an XBee module connected to Serial1

Yesterday I added code that checks the ID, MY, and DK settings in the XBee: if they are wrong then I write the proper settings. All of this is through AT commands. This is done in setup(). And this is when those issues started  .

The serial ports look to be very finicky on Arduino... One out of two AT commands to the XBee fail, and I just don't get why  . The same code works fine on another type of MCU.

Regarding delay(), it's not recommended to use it but for very short delays. Thing is, delay() freezes the MCU for the duration of the delay. I created a Wait() function that simply spends time for the duration of the delay:

while(Var > millis()) ; 

It didn't help...

Tim,

is it possible that for some reason working with serial ports from within setup() could lead to issues ?

Thanks

Strange. Are you debugging on Serial1 using the xbee?

Questions not to cause you to change setup, I just need the answers 

Have you got project debug break/pause enabled?
Is Dtr on or off on the serial window?
What speed are you using Serial at?
Does your code do anything with serial0?

Thanks

Break/Pause is in the project properties near the top. Press the yellow "?" on the vm tool bar and the properties should open as well as the explorer. 

Does your sketch code initialize serial 0 at 57600 or the xbee or both?

Thanks

The properties are probably collapsed on a tab or button in your ide. You will find them but the wiki also shows how to access project properties.

Okay so it sounds like it is working now. It was disconnecting after you pulled the power/usb or uploaded? 

The Arduino ide expects the serial monitor to be re-opened after the hardware disconnects but Visual Micro allows an intelligent auto re-connect or manual by toggling the "connected" check box.

If your sketch code is not using serial0 then why is it initializing serial0? You must have also set the LocalSpeed project property to 57600 otherwise the debug would not be working because it defaults to 115k

It doesn't matter if you use Serial.begin() in your code but it does mean that your project settings LocalSpeed and RemoteSpeed must use the speed that your code sets. Your code overrides the default Visual Micro speed setting of 115200 Break/Pause is on and Dtr is Off you have to pay more attention to the state of the Arduino. It is possible for the Arduino to have started before the debugger starts and also for the Arduino to be in the middle of running code when the debugger starts. You specificially requested that the Arduino does not re-boot when the debugger starts so you have a more complex situation to deal with. 

If the Arduino is stuck at a breakpoint before the debugger starts then the debugger will not know about it. So the Arduino will be in break/pause and Atmel Studio (or Vs) will appear to be doing very little. In this case you can use the Serial Monitor to send a C char. 'c' means Continue and this is what Visual Micro sends to the Arduino to tell it to continue from a breakpoint (F5 does this when in a break). yes it is a simple system 

Prior to switching off Dtr I think you reported the same problem. Again this will be the break/pause has been hit before the debugger had time to start-up. Normally this is not possible because the Dtr forces a re-boot when the debugger starts but it appears you have changed some of the default settings that will affect this. 

So I suggest you zip and email the Visual Micro folder below you sketch so that I can see your settings.

Thanks