[support]

Thanks for attaching the screenshot. VisualGDB should never color the regular Output window (hence we wanted to double-check you are not still accidentally using Advanced output).

We have rechecked the coloring behavior with the latest VS2019 16.6.2 and could not get the coloring shown on your screenshot. Please double-check that you are not using additional extensions that could be coloring the output. You can disable various extensions via the Extensions->Manage Extensions command.

If it doesn’t help, please try disabling the VisualGDB extension via that command and restarting VS. If the project is based on GNU Make, you will still be able to build it (although VisualGDB won’t be loaded into the VS and should not interfere with the IDE responsiveness). If this still results in a slow behavior, please try creating a regular Win32 console project and check if building it slows down VS as well.

[support]

Hi,

It is hard to say what is going on without knowing more details. Please share a screenshot of the Help->About VisualGDB window and the build errors you encounter and we can point you to the right direction.

[support]

No problem. Please let us know the email address associated with your license key so that we could link it to your support profile, and we will point you to the right direction.

[support]

Hi,

Please see the following page for instructions on troubleshooting this: https://visualgdb.com/documentation/linkerinputs/

[support]

No problem, we can help you get this to work. Please try modifying the code to control one of the LEDs from the M4 core. Then check if the core gets started when you are not debugging it (i.e. program the FLASH both memory banks and power cycle the device).

If the second core never starts outside the debugger as well, please try comparing the startup code on the first core with some example that manages to start the second core successfully. Most likely, the example is missing some code for actually starting the M4 core.

[support]

No problem. MSBuild does support common flags and linker flags via Configuration Properties -> C/C++ -> Command Line. If you need separate C/C++ flags, you can set them via C/C++->Advanced.

We do advise reading our documentation on MSBuild and STM32 project structure. It’s a long read, but it gives an extensive overview of all common settings types, and will save you considerable time long-term once you learn how to use it efficiently.

You will also get much faster build times, fewer rebuilds, single-file building, precompiled header support, and many other usability features that are not supported for Make projects.

[support]

Thanks for confirming your license. We will try to explain what is going on.

When you convert the project to a stand-alone one without copying the BSP files, it removes the references to all files from the BSP (including the linker script, register definition file, common preprocessor macros, etc). This option is intended for advanced users that would like to manually re-create the minimum necessary subset of files from scratch. It indeed will not result in a buildable project and will require some manual tweaking before you can get it to work. We have confirmed that this option left the reference to the register definition file (but did not copy it) and updated VisualGDB internally to remove the reference.

If this behavior is not intended, please try copying the BSP instead, and then remove the unnecessary files. This way you will start with a usable project and will be able to verify that it still builds after each step.

Also, depending on your requirements, you may not need a stand-alone project after all. If you want to remove the standard driver files, but keep the linker script and peripheral register definitions, you can simply unreference them on the the Embedded Frameworks page instead.

Regarding the out-of-sync Makefiles, this is a known limitation of the GNU Make build subsystem (see this page for a list of known limitations). For all new projects we advise using MSBuild instead. It does not require duplicating the settings between Visual Studio and the actual build subsystem (i.e. GNU Make) and hence eliminates many possible failure points.

If you would like to build the project outside Visual Studio, you can try out our experimental Embedded CMake integration. It combines the advantages of both GNU Make and MSBuild:

• The build is entirely managed by CMake scripts, that you can easily edit and build outside VisualGDB.
• Solution Explorer contents is rendered based on the exact CMake code model, so it’s always up-to-date.
• It also does not have multiple sets of settings for debug/release, avoiding the issue you mentioned.

The Embedded CMake projects are currently still very experimental and cannot be created using the wizard yet, but if you would like to try them out, we can share the instructions here.

[support]

Thanks for letting us know. Please feel free to attach a screenshot of the output window showing the incorrect coloring and we might be able to suggest something more specific.

[support]

Hi,

This might be caused by the way STM32H7 devices initialize the secondary core. We have a separate tutorial explaining it.

Please also make sure you are using VisualGDB 5.5 Preview 7 and not v5.4.

If it doesn’t help, please let us know and we will look further into this.

[support]

Hi,

Please see the following page for a detailed overview of supported debug methods: https://visualgdb.com/documentation/debugmethods/#avr

[support]

Hi,

You can download the old packages by setting the “show old packages” checkbox in the VisualGDB Package Manager.

We have detailed instructions on it (including the manual download steps) on this page: https://visualgdb.com/support/oldpackages/

[support]

Thanks for explaining this. We have updated VisualGDB to automatically reset the “Compile As” setting for assembly files in IAR projects. Please try this build: VisualGDB-5.5.7.3690.msi

[support]

We do test toolchain updates with VisualGDB and it should normally work out-of-the-box. Most strange errors like this one happen when trying to apply several changes at the same time and ignoring various error messages, or by modifying the project structure directly, hardcoding the paths that should be normally referenced via variables.

If you often modify the projects manually, please make sure you read this page first. It explains the embedded project structure in detail.

That said, if you can confirm that installing a specific update consistently breaks some functionality, and provide repro steps for us to reproduce the problem on our side, we should be able to fix it.

[support]

We have updated VisualGDB to match the relevant part of the log, however it may still work differently. Please try this build: VisualGDB-5.5.7.3689.msi

 

[support]

Strange. Just for the record, we have tried running VisualGDB /scanlog on the file you attached, but it only took ~100 msec, so the problem must be elsewhere.

Also it’s hard to say whether you are using the regular output, or the advanced output window. Please attach the screenshots of the output window and the settings where you disabled the advanced output (make sure you restart VS after changing the output settings) so that we could see what is going on.

Also please try narrowing down the slowdown, e.g. whether it happens:

• On first build after starting VS or after some time
• With any project, or only a specific project type
• With any amount of output, or only if the build produced large output amounts

Additionally, if you could make a quick screen video showing the problem, we might be able to narrow it down faster.

[Author]

Posts