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

[support]

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

[support]

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?

[support]

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.

[support]

Hi,

Thanks, we will consider adding a tutorial specific to IAR.

[support]

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.

[support]

Hi,

Yes, you can fully customize the embedded project templates, device definitions, etc. VisualGDB stores them in XML files under %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs. While the format is not documented or officially supported, we try to make it as self-documenting as possible and if you encounter any questions with it, feel free to ask for advice and we will point you to the right direction. You can also look through the sources of the tools that generate BSPs for the families supported by VisualGDB – they are available on our Github repo: https://github.com/sysprogs/BSPTools/

Regarding the peripheral library, you can simply convert your project to a stand-alone one and VisualGDB will copy all the necessary files for you.

Regarding the toolchain, we want to minimize the amount of maintenance (and possible bugs) with the toolchain, so we ship one toolchain for all supported ARM cores. Deleting the cortex_a directories should not interfere with cortex_m compilation, so feel free to repackage the “lite” version of the toolchain for your own use or share it with the community. Just please change the toolchain ID in toolchain.xml to avoid confusion with the original toolchain if you want to redistribute it.

[support]

Hi,

Yes, the embedded frameworks look correct. The nRF5x.xml file should be located in your project directory. If you are not sure about it, the EmbeddedProfile element in your .vgdbsettings file should contain the relative path to that file:

    <EmbeddedProfileFile>MCU.xml</EmbeddedProfileFile>

[support]

Hi,

Sorry, something things are buggy. We do have plans for a better file synchronization engine that will detect such cases, but it’s hard to say whether it makes it to v5.3, as it is a fairly complex feature and such bugs are relatively rare.

[Author]

Posts