[support]

Hi,

The easiest way to run multiple commands would be to create a batch file in the project directory and run it as a custom post-link step. Simply copy the command lines for objcopy and other tools from a build log of a Make-based project and replace the project name accordingly. VisualGDB will then run the .bat file with those command lines each time after a successful build.

[support]

Hi,

We are not aware of any side effects of FLASH erasing that could cause JTAG issues, so this could be a side effect of inconsistent power supply or cross-talk, or could also be a limitation of a specific STM32 core. We would advise double-checking this with ST.

A possible workaround would be to erase the FLASH memory page-by-page instead of doing one massive erase operation – this might work around the issue.

[support]

Hi,

For MSBuild projects you can use the custom post-build step in the Linker settings or custom post-compile step in the C++ settings. Another option would be to create a custom MSBuild target (this approach is more complicated, but is very well documented by Microsoft).

The custom post-build actions provide a convenient GUI for managing those steps, hence they are included in the more expensive Custom edition, but you can always achieve the same results through scripting the steps manually (although this requires extra effort).

[support]

Hi,

We usually update our STM32 packages quarterly, so we are planning to release a new update within a month. The mbed package is updated less frequently – the current plans are to release the next version around April-May.

If you don’t want to wait, you can also try running our open-source BSP generators on the latest versions of the packages, however we don’t guarantee that they will work until we officially support the new versions.

[support]

Hi,

No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2039.msi

[support]

Hi,

No problem, we will test this as a part of the v5.4 release cycle and post an update here once it is fully tested and supported.

[support]

Hi,

Good to know it works. If you encounter further problems, do not hesitate to post another thread.

[support]

Hi,

Please use the following option to disable it: Tools->Options->Text Editor->C/C++ (VisualGDB) -> Advanced -> Typing Assist -> Auto-match brackets (you may need to reopen the source file for the changes to take effect).

[support]

Hi,

OK, the official VisualKernel 3.0 Beta 1 is ready: https://sysprogs.com/files/VisualKernel/VisualKernel-3.0-beta1.msi

It has passed all our internal tests and includes many new features. We will do an official announcement with the detailed list of new features on Monday.

[support]

Hi,

The LXSS root directory is currently cached until you restart Visual Studio, so if you changed the default key after starting VS, it could get an invalid value.

With VisualGDB menus, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2037.msi

We will try to provide better support for multiple LXSS installations in v5.4, but we can still help you resolve the issues you encounter currently. If you can still confirm inconsistent behavior with WSL paths, we can send you another diagnostic build with further logging that will help pinpoint this.

[support]

Hi,

Thanks for the dump file. This actually looks like a known Clang bug that we have not been able to pinpoint yet. Clang crashes while trying to parse a comment after an #ifdef directive. If you could locate the place in the code responsible for this and send us a repro, we should be able to fix it.

Another option (if you could get this to crash consistently) would be to try a debug build of the engine (https://sysprogs.com/files/tmp/CppEngineCore64.7z) and send us a full dump (if you get an ‘assertion failed’ message, please attach VS, click ‘retry’ and create a dump file). This should help us pinpoint and fix this.

[support]

Hi,

Strange. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.18.2024.msi

It will show the command line it is trying to run as a part of the exception message. Please try running the same command line manually and see if it shows any meaningful errors.

[support]

Hi,

If you are using a Custom edition of VisualGDB, you can change the SDK location via the first page of VisualGDB Project Properties. You can also conveniently share this setting with your colleagues using the Team Settings feature.

If you are using a lower edition, the only way to change the paths would be by manually editing the .vcxproj file.

You can always upgrade your edition here: https://sysprogs.com/splm/mykey

[support]

Hi,

Thanks for pointing this out – we have switched the bootloader file definition and fixed the ESPImageTool binary. Please download the r13 toolchain here: http://gnutoolchains.com/esp8266/

Regarding the OTA scripts, our toolchain is based on the original ESP8266 SDK. If you believe it is missing files for some of the OTA modes, please double-check this with Espressif, they might be able to provide you with the correct linker script.

[support]

Hi,

The easiest way to resolve this would be to manually add a statement filtering out the excluded files to Makefile (using the $(filter–out …) syntax).

Another option would be to patch the VisualGDB MSBuild platform files to run your compiler instead of the gcc. If the Intel compiler command line is compatible with the gcc command line, we can add an option to override the gcc executable via Project Properties. If not, you would need to create a file similar to gcc.xml (in VisualGDB directory) describing the command-line options for the Intel compiler. Let us know if you would like to try this out and we will provide you with a build that allows overriding the compiler name.

[Author]

Posts