[support]

It looks like you broke something in the platform files:

Error reading file (C:\Users\gwerderj\Documents\ArduinoData\packages\arduino\hardware\avr\1.8.1\boards.txt:0): Invalid line format, should be ‘key=value’

The easiest way to fix it would be to just delete the arduino\hardware\avr folder, restart VS, and let VisualGDB download all the necessary packages from scratch.

[support]

Thanks for pointing this out. Indeed, one of the recent VS2019 updates has changed the internal color encoding used by VS, triggering this bug.

We have fixed it in the v5.5 branch and also updated the v5.4 installer, in case you prefer fully tested stable releases.

[support]

Thanks for the suggestion. We have added a “File->Open->Open a Remote File via SSH” command to the following build: VisualGDB-5.5.2.3402.msi

Let us know if you have any feedback on the new feature.

[support]

Indeed VisualGDB is not designed to parse a complex system of QMake-specific project files and extract the precise project structure from them, as that would basically require re-implementing most of the QMake logic inside VisualGDB. This is also the reason why we suggest using CMake for all new projects, as CMake can export the exact project structure in a machine-readable way, so VisualGDB gets a 100% precise IntelliSense setup and Solution Explorer view.

[support]

Hi,

Most likely, you have not referenced the LwIP library required by the STM32Ethernet library. Please try this build: VisualGDB-5.5.2.3399.msi. It will warn about the missing dependencies when you try to reference the libraries.

We have also published a detailed tutorial on the library-related logic here: https://visualgdb.com/tutorials/arduino/libraries/. We used the STM32Ethernet library as an example, so the setup shown there should be very similar to yours.

[support]

Hi,

It looks like the project might contain some settings specific to the older toolchain and would hence require changes in order to be ported to the newer toolchain.

Based on the disassembly, the contents of the _init symbol is incorrect (filled with 0xFFs), so we would advise finding where it comes from using the .map file and disassembling the .a file that provides it to see if the file is corrupt, or doesn’t make sense with your core/FPU configuration. You can also try creating a new project from scratch, ensuring that the static constructors work in it, and then comparing the _init symbol contents, the .a files mentioned in the .map file and the initialization behavior.

As another alternative, you can always revert to the old toolchain via Tools->VisualGDB->Manage VisualGDB Packages.

It also looks like your technical support has expired a while ago, so please consider renewing it here (although we won’t be able to troubleshoot project-specific issues and can only advise the general direction in such cases).

[support]

Sorry, if a project does not build outside VisualGDB, there is no way to generate a meaningful VisualGDB-based project that would somehow fix the build.

You can generate a project that will show the source files in Solution Explorer using the “import” mode of the wizard (it will simply add all files from the specified directory), however it will still invoke QMake when building, and hence will not resolve the build issues.

[support]

Hi,

Thanks for reporting this. Turns out, multiple instances of Visual Studio sometimes reuse the same external process for MSBuild-based builds, causing invalid values to be cached on the VisualGDB level.

Please try this build, it fully resolves the problem: VisualGDB-5.5.2.3397.msi

[support]

Hi,

Just to double-check, are you able to successfully build that project using the command-line tools (i.e. qmake) on the Windows machine using the same toolchain/target combination that you intend to use with VisualGDB?

[support]

Unfortunately, the internal structure of the latest QMake has changed in a way that does not allow VisualGDB to patch it to work with the Raspberry Pi cross-toolchain.

Simply replacing the QMake executable with a newer version will not work (you can verify this by downloading QMake from any other Qt package). As Qt is now fully compatible with CMake without any special patching, we recommend using CMake for all new targets that are not compatible with the old QMake that could be easily patched.

[support]

According to our best knowledge, there is no version of QMake that will work with the latest Raspberry Pi cross-toolchain. If such a version is ever released, we should be able to integrate it into VisualGDB promptly.

VisualGDB still supports QMake, as long as it is compatible with your toolchain/target combination. We do not release any special versions of QMake and do not control its compatibility with various platforms and targets.

[support]

Hi,

Generally, we are not able to resolve compatibility issues between 3rd-party components as a part of VisualGDB. However, we are happy to support the tool/platform combinations that do work reliably and provide convenient interface for developing projects for those configurations.

If you would like to get a time/cost estimate on customizing 3rd-party products beyond the supported configurations, please contact our sales, as the estimates are made on a case-by-case basis.

• This reply was modified 6 years, 1 month ago by support.

[support]

Hi,

Yes, please try using the older toolchain based on the Raspbian Stretch distribution (you would also need the older SD card image). It is compatible with QMake and will work out-of-the-box.

Unfortunately, we are not able to provide guidance on porting a 3rd-party framework to an unsupported 3rd-party platform as a part of our regular product support, however we might be able to create a port for you as a part of our paid consulting services. Please feel free to reach out to our sales if you would like a quote.

[support]

Thanks for clarifying this. Normally, VisualGDB should automatically detect the /usr/include/c++/8 directory after querying your toolchain, so you wouldn’t need to specify this directory manually. If you ever find the manual setup too annoying, feel free to get back to us and we will help you get the fully automatic setup to work correctly.

[support]

Hi,

Please make sure you use the VisualGDB 5.5 Preview 1, not v5.4.

Also you need to install the IAR compiler separately, and make sure you have a valid license for it (see this tutorial). We are not affiliated with IAR Systems, so VisualGDB can integrate with an existing IAR installation, but cannot redistribute it independently.

[Author]

Posts