[support]

Thanks for the log files. It looks like the hardware directories and libraries used by VisualGDB vs. Arduino IDE are indeed different. Specifically, the following options are used by Arduino IDE, but not by VisualGDB:

-tools C:\Program Files (x86)\Arduino-1.8.9\hardware\tools\avr 
-tools C:\Program Files (x86)\Arduino-1.8.9\portable\packages 
-libraries C:\Users\Ian\Documents\Arduino\libraries

The following options are used by VisualGDB, but not by the Arduino IDE:

-hardware C:\Program Files (x86)\Arduino-1.8.9\portable\packages\STM32\hardware 
-hardware C:\Users\Ian\AppData\Local\Arduino15\packages 
-tools C:\Users\Ian\AppData\Local\Arduino15\packages 
-libraries C:\Program Files (x86)\Arduino-1.8.9\libraries 
-libraries C:\Program Files (x86)\Arduino-1.8.9\libraries\u8g2\ 
-libraries C:\Program Files (x86)\Arduino-1.8.9\libraries\STM32duino-bootloader-master\Arduino_STM32-Drivers

Also the STM32 tools used by the Arduino IDE vs. VisualGDB are different:

C:\Program Files (x86)\Arduino-1.8.9\portable\packages\stm32duino\tools\stm32tools\2019.10.9

vs

C:\Users\Ian\AppData\Local\Arduino15\packages\STM32\tools\STM32Tools\1.3.0

If looks like you have tried adding some of the missing directories from the Arduino IDE to the VisualGDB settings and ended up with an incompatible combination of packages.

In order to fix this, please try deleting the %LOCALAPPDATA%\VisualGDB\ArduinoSettings.xml file and the %LOCALAPPDATA%\Arduino15 directory and restarting Visual Studio. Then open VisualGDB Arduino Settings and set the following:

1. Set the Arduino IDE directory
2. Add $(ARDUINO_ROOT)/portable/packages (without the STM32\hardware part) to Hardware Directories.

Do not add any library or tool directories. If the project still doesn’t build afterwards, please check the command line used by VisualGDB again. Its -hardware, -tools and -libraries flags should match the ones used by the Arduino IDE. If not, use the VisualGDB Arduino Settings to adjust them until they fully match.

If this still doesn’t help, please share the updated build log and we will provide further troubleshooting instructions.

 

[support]

Hi,

Most likely, the Arduino IDE and VisualGDB are using different library directories, preventing VisualGDB from locating them. We can help you resolve this, however we would need additional information from you.

1. Please capture the exact arduino-builder command line used by VisualGDB (it is shown in the build log after you build the project).
2. Please try using Process Monitor to capture the command line used by Arduino IDE to build the sketch. (note that the IDE will launch arduino-builder.exe several times with shorter command lines before the actual build).

Once you capture both command lines, please share them here along with a screenshot of the VisualGDB’s Arduino Settings and the list of additional library directories defined in the project settings (if any) and we will help you replicate the build results from Arduino IDE with VisualGDB.

[support]

Please try creating a new project from scratch. Please also update to VisualGDB-5.5.2.3403.msi​. This version will download missing packages when you open the project, given that it was fully loaded before (won’t help for projects that were never loaded with the new build).

[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 5 years, 10 months ago by support.

[Author]

Posts