Hi! I'm try to start with a new board (Teensy4.1) I have problem to lunch the debugger. I'm looking for around the forum but I can find nothy about this error. Can you help me?

This is the error output
Type "apropos word" to search for commands related to "word". =cmd-param-changed,param="pagination",value="off"
The program '' has exited with code 42 (0x2a). :) ;D ;D

Thanks for the report, and this error often means the connection could not be established with the board, but as there is no manual wiring there must be another issue.

Please enable the below options:

• vMicro > Compiler > Show Build Properties
  
• vMicro > Compiler > Verbose
  
• vMicro > Uploader > Verbose
  

Then Run: Build > Clean

Then run: Debug > Start, and attach the full output from the Output Window > Micro Build.

We should be able to assist further from there.

Hi, here the microbuild output file .txt

---

Thanks for the detail.

Can you confirm that after upload there are two COM ports shown for the Teensy Board in Visual Micro (assume COM8, and COM9)?
There should be the additional line of code in Setup() e.g. debug.begin(SerialUSB1);

On the vMicro > Debug > Debugger Menu there should be an additional option to "Override COM Port", which in the above scenario would be set to e.g. COM9 with the upload port left as COM8.  Once this is set as well it should allow attach to process to work as expected.

Hi Simon
I can confirmo the following configuration:

setup ()
SerialUSB1.begin(115200);
debug.begin(SerialUSB1);


yes, the  COM ports shown for the Teensy Board in Visual Micro (assume COM9, and COM10)

this last update micro build report (no verbose)

=thread-group-added,id="i1"
GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160923-cvs
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
=cmd-param-changed,param="pagination",value="off"
The program '' has exited with code 42 (0x2a).

and for last in debug menu the option is set to over ride COM10. I have tryd with COM11 but noting the debug do not start again.

:o

Any idea?

Thanks for the detail.

From the code I believe your code, and the debugger are trying to use SerialUSB1.

Try changing it to:

Code (]setup () {
Serial.begin(115200);       // First Serial Port in Dual Serial Mode for our code [COM8):

debug.begin(SerialUSB1); // Second Serial Port in Dual Serial Mode for Debugging Transport [COM9] }

I have tryed with code provide but nothing doesn't go again.

Now I can upload the code without error, but when I try to lunch the debugger I have an :( error, reported below...
The program '' has exited with code 42 (0x2a).

>:(

Thanks, can you please attach the full Output again so we can investigate further?

Hi, in attach the micro build file output.
;)

---

Thanks for the detail.

If you Upload the Sketch, both Serial Port Selections should allow the COMxx port to be selected (instead of the Teensy designated \\usb:0/140000/0/4/3\)

At present it looks like the option on the vMicro > Debugger > Override Debug Port is set to \\\\.\\usb:0/140000/0/4/3\, instead of the native COMxx port.

If you reselect the port after uploading, and try again this should work as expected (attach new log if issues occur).

Hi,
in attach last report
I managed to get debugging working by adding  COM11, but when it's start the debug stay in indefinite state, is not possible to set a breakpoint, or watch a variable, nothing is possible to setup. The only command accepted is the stop debug command.

:o

---

If you set the vMicro > Debug > Optimization to "No Project + Libraries", and set a breakpoint at the top of loop in your sketch, then Debug > Start, does it land on the breakpoint?

Hi, doesn't work! Same problem. Again the Type "apropos word" to search for commands related to "word".
=cmd-param-changed,param="pagination",value="off"
The program '' has exited with code 42 (0x2a).

Please attach the log...

The error simply means that GDB cannot connect to the software stub via the COM port on the board.

Does using Debug > Attach after uploading the code improve the situation?

Hi!
I can see this.
1. if I try to compile and then upload all works very well without problem, the board start and run.

2. after this if I try to START with debug the debug doesn't start and send an error.

I  also tried pressing the reset button on the board, but nothing, same error.
:o

Marco (Italy) wrote on Apr 6^th, 2021 at 4:14pm:

2. after this if I try to START with debug the debug doesn't start and send an error.

If you use the Debug > Attach to Process, this will just attach the debugger, without doing the build/upload again.

It may be the Debug > Start Debugging, is trying to start the debugging process too quickly.

if i try to start debugging using <attach to process> from the debug menu, visual studio displays a window saying <initializing debug> and after about 30 sec. the usual error appears.
is It looks like it can't find the debugger?

;)

Can you ZIP and send the entire solution to us via email, and an up to date copy of the full build output?

Hi
in attach the entire solution in zip format

;D

---

Hi,
here the full list of micro build

---

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.

Hi, sorry but it doesn't work. Exactly the same as before, debugging is not started.
:o

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  :-/

Thanks for the update.

To get into the setup() code, you can add a delay after the debug init, or wait for something to be sent via the normal serial comms to continue execution.

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.

:-[

UPDATE
using a delay(35000); the debuf work well.
yes, is not a elegant solution but work
now I can:
1- insert a breakpoint in to setup
2- the code flowing is stopped correctly on  breakpoint
3- the F10/F11 work well step-over/step-into

could this discussion be used to think of a more robust solution in VM? Could this discussion be used to think of an VM update that would provide greater stability, without having to wait 25 seconds for debugging to start? For me there is a issue about the selection COM10 - COM11 how I can understand wht COM I need to use for debug? Actually I need to try com10 or com11 , but is not a "great" solution.
:)

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.

Our posts crossed. Good to hear you have it working. Hopefully my last comments show you why this happens and that it is not something that Visual Micro or any other IDE could control.

There is a define #VM_DEBUG_GDB  that can be used to include/exclude code when debugging


Code (c++):

#ifdef VM_DEBUG_GDB   //some debug only code here #endif

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?

;D

Looks ok to me, let me know if doesn't work.

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

;)

Maybe some confusion in what I have said. The condition using an #if is simply to allow you to add code that only works/compiles when gdb debug is enabled. All other settings such as pause time for teensy gdb stub are unrelated to my suggestion.

Here is a clear example. Visual Micro is set to GDB Stub but I have not initialized or used GDB in the program code.

The code example prints "test" to serial ONLY when GDb is enabled. In this case enabling GDB but not using GDB allows us to demonstrate how the #ifdef works.

Serial is only active when GDB is selected in Visual Micro ...


Code (c++):

void setup() { #ifdef VM_DEBUG_GDB      Serial.begin(115200); #endif } // the loop function runs over and over again until power down or reset void loop() { #ifdef VM_DEBUG_GDB      Serial.println("test"); #endif }

[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 ;D

Well done, yes you have to wait for some serial ports before they can be used. You can do this early, not sure you need the delay.

[code]void setup{

while(!SerialUSB1)
{}      

Serial.begin(115200);
debug.begin(SerialUSB1);

}[/code]