Forum Replies Created
-
Posts
-
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.
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.
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.
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.
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.
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.
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.
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.
Hi,
We do have a tutorial for that: http://visualgdb.com/tutorials/arm/standalone/
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.
Hi,
If your program never goes beyond that line, it means that your PLL never gets a stable frequency output. This may happen if the PLL multiplier/divider settings are incorrect for your board (e.g. the project you are building is meant for a different board with a different clock crystal).
Hi,
Sorry about that, we are not aware of this issue, but will be happy to help you pinpoint it. Do you get a message like “gdb command xxx is taking too long” in the GDB Session window while VisualGDB locks? If no, is the Visual Studio GUI responsive, or does it totally hang? If it hangs, does killing CppEngineHost.exe via Task Manager unfreeze it?
Hi,
First of all, we recommend using MSBuild instead of GNU Make as it is more flexible and requires less workarounds on the VisualGDB side.
If you want to use Makefiles nonetheless, please add a dependency and then rebuild the solution. Do you see both projects being build in the correct order? If no, please attach the build output here. If yes, please let us know what does not work.
Hi,
You can tweak the Clang IntelliSense behavior by adding Clang-friendly command-line flags to “Additional flags for C/C++ files” fields on that page (e.g. -DSOME_MACRO). The IntelliSense is actually using Clang, so all Clang flags that are relevant for source parsing should be supported. If you are looking for a specific setting, let us know and we will suggest a flag that controls it.
