Hello,

Lucky to have set some Debug-Tracepoints, I let work my Arduino Leonardo without USB/Port connection.
But - at some point I had to reboot the arduino - still powered by an external powersupply.
At this point I realized, the the Arduino doesn't boot (it did not enter the Setup()!  ) till I reconnected the USB/Port to Atmel Studio.

My Goal was, to have the Arduino working with some tracepoints enabled, so I can reconnect at a later time to see how it works...
But it seams, that this would cause some problems in case of a reboot.

Is it by designe - spezific to Leonardo?

Thank You
Thomas

Sounds like someone somewhere has the line  while(!Serial); in their code.

Tim@Visual Micro wrote on Nov 1^st, 2013 at 1:17pm:


Being nitpicky but technically you need more than that.  You could be plugged into a USB but it won't return true until the com port has been opened (such as Serial monitor).  Just being plugged into a USB port won't make Serial return true.

Tim@Visual Micro wrote on Nov 1^st, 2013 at 1:17pm:


In your case timing out makes more sense than flat out blocking until Serial is true.   A person may want to debug a running program at a later time.  The Serial object still works and you can reconnect to it anytime.  

By the way, if Thomas has an FTDI cable or uses Xbees an easy workaround would be to configure the Remote Port project properties to "Serial1".   Serial1 on the Leonardo & Micro are digital pin 0 and 1 and it doesn't block at all.

I can confirm I can remotely debug a Leonardo using an Xbee shield in this manner.

Hello again!   
 
Happy to see, that my english is good enough - so you are able to understand the Problem... 

@Dennis:
That was my first thought: oh sh..t, I have left the while(!Serial).
But that wasn't the case - at least not in that part of code I'm working with... 

If I understood right, there is some other part of code where VisualMicro is dealing with.
I`d like to piggyback a further finding with this `usb/Serial-port`.
As Dennies mentioned before, the debug-behavior depends on the `open Serial connection` from the IDE (I use Atmel Studio 6.1 SP2)
The old way of debugging with the Serial.print() showed me, that at least with the arduino IDE 1.5.4 the arduino booted up and run the code even though in my code stod a  while(!Serial) in the Setup().
I realized that the IDE didn't time out the Serial-Connection quick enough when I redeployed the code. This way, my Leonardo booted up, saw the `old` Serial Connection and went on. I had to add some more code so it looked like this:
delay(4000);  // wait ca. 4 seconds to Close the previous Connection.
while(!Serial); // await the new ser. Connection...

May be that is relevant to you.

Best regards
Thomas

PS: at the moment I deployed the code without `debugging`... but this way I will mess up the remaining Problem in my code...   

Hello Tim,

You were clear.
My thoughts on this while(!Serial) were before I posted here ( I doublechecked my code before...      )

So, there are two situations:
S1:
- I'd like to debug the  Setup() - so the Debugger should
   wait till the Serial Connection is opened.
S2:
- I'd like to debug some other code, some time in the
   future, so the Debugger should not wait till the Serial
   connection is opened.

Waiting some seconds will probabely solve the Problem in most situation  (presumed, I reconnect the serial connection quick enough).
The other way round:
What happens, when I interuppt the serial connection while debugging (are there any buffers that will overflow on the arduino, etc.)?

Thomas

In the next release, Visual Micro waits for the 5 seconds for the  serial to become active then allows the program to continue regardless of Serial connection. This applies only to debug using the main serial port of usb "aware" processors such as is on the Leonardo and Teensy boards.

This allows a program compiled with debugging to run when no longer connected to usb. It is not recommended to run a debug version in a release environment but useful for testing purposes only.

ps: make sure your own code does not have "while (!Serial){}", this is what causes it to wait for usb connection