Thanks for the detail.

From some further testing using your project today, it seems the most reliable solution is:
1) Set vMicro > Debugger > Optimization: No Project
2) Set a breakpoint at the top of loop()   (If this is not put in, further breakpoints do not bind)
3) Build and Upload
4) Use Debug > Attach to process

The Debug > Start attaches before the COM port is available, so using Attach to Process is more reliable with this particular library.

UPDATE:
setting COM11 instead of COM10 the debug is runnig. 
But (there is alway a but in our life!)
The debug
1- do not start with START button but only with attach to process
2 - is not possible to set a break point in SETUP
3- if you do not place a break point in loop() before to compile, during debug session is not possible to add any breakpoint

in not easy to use this debug with teensy4.1 

Hi!
this is my code:
void setup() {
     Serial.begin(115200);       // First Serial Port in Dual 
     debug.begin(SerialUSB1); // Second Serial Port in 
     delay(5000);

using a 5Sec. (too low?) delay the situation do not change.

1- is not possible to setup a breakpoint in to setup
2- some time the debug do not start with COM11 I need always to upload the code if I want restart the debug using the attach process menu.

Hi Marco,

Each hardware debug solution comes with different restrictions. That is just how they work. We can only give tips as to possible workarounds in some cases. Non of this relates to things Visual Micro can control, it is how the hardware debug authors have designed things for each type of hardware.

In the case of a GDB stub there are always additional restrictions but you can think it through yourself and sometimes find solutions. The two issues you report are related to the teensy board and how the GDB stub works for the Teensy board.

We produced the serial debugger because it avoids many of the restrictions but you still need to consider what is happening to find solutions.

The issues are especially difficult with Teensy because it has a different upload facility to all other boards. It performs the upload each time you build, then the mcu starts. This all happens a long time before debug starts. The attach to process instead of debug start gets around some of the issues of the mcu starting early but makes debug setup tricky. 

Putting all this together, the design of the GDB stub solution for Teensy makes it quite difficult to jump into the setup() code. I think there can be a solution but it isn't clean. It might involve the mcu waiting in the setup() until it receieves a serial message from thje pc telling it to continue. You would send the serial from the pc after debug is started and waiting. All in all hardware debuggers as opposed to stubs handle this better as do other boards. For the Teensy the best solution is probably the serial debugger.

Hi Tim!
thanks for your assistance. the code that you provide me is right used in this mode?

Code (C++):

#ifdef VM_DEBUG_GDB
      debug.begin(SerialUSB1); // Second Serial Port in
      delay(5000);
#endif 
so, this code is selected only when the debug is connected?

Hi Tim!
the code doesn't work, same problem!

[SOLVED]
 
Hi Tim
this code work fine !

void setup{
Serial.begin(115200); 
debug.begin(SerialUSB1); 
while(!SerialUSB1){}       
delay(500); // min 200mSec. 500mSec. for safety
}

Tomorrow I will open a new thread for a new issue ... but for Arduino Zero using the ICE Atmel debug.

See you tomorrow!
Marco