[support]

Hi,

If the regular C++ Console project does not work, something is definitely wrong with the VS installation. If repairing it does not help, please try completely removing it and installing it again.

[support]

Hi,

This behavior is somewhat by design. The Clang IntelliSense aims for high accuracy, so it needs to fully parse the source file before it can do code suggestions. If the file was modified in the last 24 hours, VisualGDB considers it to be an actively edited file and creates a “preamble” – precompiled snapshot of the header files used by the file, so subsequent IntelliSense operations work very fast. The high CPU usage by CppEngineHost.exe is normal – this is the process that hosts the IntelliSense engine (we don’t run it inside Visual Studio so that Clang crashes would not crash Visual Studio itself).

You can see what exactly is going on via the View->Clang IntelliSense Diagnostics Console.

In our tests, the first parse usually took 3-6 seconds, but never 35-45. Could you let us know which hardware you are using? Also if your project is located on a network drive, please consider copying it locally as accessing many .h files over network will be very slow.

Another optimization tip we would give is to use precompiled headers. If VisualGDB detects that over 80% of the project files include the same header file at the beginning, it will automatically treat it as a precompiled header, greatly reducing the parse time for new files, even if your build system does not support precompiled headers and is treating it as a normal header file.

[support]

Hi,

Your device may not stop the DMA clock while the CPU is stopped in the debugger, so this could cause some buffer overruns or other similar problems. We would recommend checking the UART and DMA registers to understand what exactly happens and then checking through the device documentation for ways to pause UART/DMA during debug stops.

[support]

Hi,

The newlib-nano library does not include semihosting code by default. We normally recommend referencing the “Fast semihosting & profiler” framework to get a much faster semihosting interface that works with all types of the standard library.

[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.

[Author]

Posts