[support]

Hi,

This is a tough one. You can use custom actions to select a specific process (or wait for it to start) once you hit F5 in Visual Studio, but automatically attaching to each new process is something beyond VisualGDB capabilities. We would advise instead configuring your system to create crash dumps when the process crashes or programmatically running an infinite loop if a crash is detected so that you have time to attach manually.

[support]

Hi,

Please check the Output window of Visual Studio for details on the error. It should explain why the link fails.

[support]

Hi,

This looks strange. Please double-check the following:

• The .link.rsp file in the Debug directory should mention object files for both binaries (bootrstv.o and the other binary)
• The bootrstv.o should contain one symbol in the .bootrstv section
• The second .o should contain one symbol in the other section. The symbol names for 2 binaries should be different to avoid conflicts between them.
• Your linker script should mention both section names using the KEEP syntax.

You can view the contents of a .o file with arm-eabi-objdump.

[support]

Hi,

Thanks for the video, it really helped reproduce the problem. Turns out, it was a race condition between live variables and live memory initialization.

We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1337.msi

[support]

Hi,

Do you get it for all kinds of projects? Are you able to create and debug a normal Win32 Console Application with Visual Studio? Could you also share a screenshot of the error and let us know at which exact stage it occurs?

[support]

Hi,

The MSBuild system already supports embedding binary files into projects (e.g. see this tutorial), although the resources are normally added to the .rodata section.

We have added an option to specify the section name (e.g. .bootloader) for each binary resource file to this build: VisualGDB-5.2.14.1335.msi

Please try adding the .bin file to the project, opening file properties for it, switching the type to ‘Embedded Resource’ and then changing the section name in Embedded Resource->General to .bootldr. Don’t forget to update your linker script to actually place the .bootldr sections at the correct address.

 

[support]

Hi,

Based on your description, you have set Live Variables to some scope-dependent objects (e.g. static members of a class) without using the full scope (e.g. s_Variable instead of MyClass::s_Variable). Next time you start the debugging session, VisualGDB would evaluate ‘s_Variable’ when the program starts, not find it (because the program is not in the scope of MyClass yet) and consider it deleted. Please try using fully qualified names for your variables to fix this.

If you are not sure, please switch the GDB Session window to All GDB Output mode and check for commands trying to evaluate the variables you added in the previous session. The output from gdb should explain why they fail.

[support]

Hi,

The Shift-F5 is actually a VS bug (if you press it before VisualGDB reports that the session is started, VS waits for 30 seconds before actually stopping). Normally if some commands are hanging, the GDB Session window should display a message about and allow aborting the session from it.

Regarding the other warning, the “suspicious Pseudo-TTY path detected: sh: tty: not found” simply means that VisualGDB could not get the name of the pseudo-tty it created (if the main method of creating it fails, it runs the ‘tty’ command). Adding ‘tty’ path to the $PATH variable on your Linux machine should completely resolve this.

[support]

Hi,

This is actually configurable globally via Tools->Options->Fonts and Colors->Text Editor (another bunch of options is under Tools->Options->Text Editor->C/C++ (VisualGDB)).

The highlighting colors should be managed normally by VS though, so if you believe they are broken, please attach a screenshot so that we could suggest how to fix this.

[support]

Hi,

Thanks for confirming this. We have added automatic directory creation to our development branch and will include it in the next maintenance release. Please let us know if you want an early hotfix build.

[support]

Hi,

The clock crystal is not a part of the chip – it’s an external component on the board. I.e. 2 different boards using LPC11U24 may use 2 different clock crystals (e.g. 8MHz vs 25 MHz) and the initialization code for one of them will trigger the PLL problem you are observing on the other one due to the difference in frequencies.

When you select the LPC11U24 in VisualGDB, it uses the default system file that is shipped with mbed; the online version may actually use a file provided by your board manufacturer that is not a part of the regular mbed distribution that VisualGDB uses. Please try exporting your mbed project from the online compiler and use the system file and the configuration files from it.

[support]

Hi,

If the debugging works as expected (e.g. the breakpoints trigger), but the LED is not blinking, it could be caused by one of the following:

• The LED is actually connected to a different pin
• The LED bank is not initialized properly (e.g. clock is not enabled for it).

We would recommend first double-checking the board schematics and then using the Hardware Registers window to check the GPIO registers and see if the direction, type and value are set properly for the pin you are using.

If other GPIO pins work, but this one does not, something on the board might be pulling it down or the GPIO driver on the STM32 chip may be physically damaged, so trying a different board should help.

[support]

Hi,

This might be an SSH-related bug. If you could try attaching another VS instance to the hanging instance, create a dump file and send it to us, we should be able to tell what is causing this and provide you with a hotfix.

[support]

Hi,

We do have a tutorial for that: http://visualgdb.com/tutorials/arm/standalone/

[support]

Hi,

Looks like Make is having trouble launching make2728-1.bat. This does not look like anything generated by our Makefiles, so please check that you have enough free space on the disk and check the full build log to understand which part of the build process produces this.

[Author]

Posts