[support]

Hi,

Yes, unless the pre-release testing reveals major unsolvable regressions caused by the new feature (highly unlikely in this case), all features added to daily builds will be included in the next upcoming release.

[support]

Hi,

It looks like some include directories from the CooCox project were not imported properly.

The easiest way to resolve this is to find the location of the missing files when compiling with CooCox. Most of the GCC-based projects use .dep files for dependency tracking – those files (generated by gcc) contain full paths of all header files included by a source file. Please try building the CooCox project and then search its build directory for .dep (or .d) files containing the names of the missing headers (e.g. hw_cmsis_core.h). If none are found, try searching in all files. Once you locate the directory of the missing files, please add them to your imported project (either via VisualGDB Project Properties or using header discovery).

If you run into further problems, feel free to post the details here and we will help you resolve them.

[support]

Hi,

No problem. We have just replied to your new inquiry. Let us know if you have any further questions.

[support]

Hi,

We have quickly rechecked the “blinking LED” project on the DISCO_V407VG target, but could not reproduce the crash. The linker scripts generally come directly from the mbed distro and are outside our control, so we are not able to offer any more backward compatibility than mbed itself does, sorry.

Please try checking whether a basic “blinking LED” project works with your device. If not, this could be a compatibility issue between the toolchain and the mbed BSP, so installing the latest ARM toolchain might fix this.

If the “Blinking LED” project works, please try comparing the initialization code of both projects to see if any of your code could be relying on the old linker script.

Another way to pinpoint this would be to try building your project with mbed-cli and then debugging it via Quick Debug (or by replacing the ELF file and not rebuilding the VisualGDB project). If the project built with mbed-cli works and the one built with VisualGDB doesn’t, this is likely our bug and we should be able to fix it if you could let us know more details (e.g. map files for both projects).

 

[support]

Hi,

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

We have added a new command-line option for filtering tests: /testregex:<regex>.

If the filtering is not working as you expected, please set the VISUALGDB_VERBOSE_OUTPUT environment variable to 1. This will force VisualGDB to show the full test names it matches against the regex.

[support]

Hi,

Thanks for reporting this, looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2348.msi

[support]

Hi,

Good to know it works. If you encounter any further problems, please do not hesitate to contact us again.

[support]

Hi,

The new advanced ESP-IDF project subsystem was added to VisualGDB 5.4 Preview. Most likely you have installed v5.3 that doesn’t have this feature yet (and won’t install the latest toolchain). Please ensure you install the v5.4 preview version. Also if the old toolchain cannot be removed from VisualGDB, please try closing all Visual Studio instances and simply deleting the toolchain directory from Windows Explorer.

[support]

Hi,

According to our records, your inquiry was answered on 06/20/2018 8:18 pm in less than 8 hours from the time we received it.

Please double-check your spam folder and let us know if you would like us to resend the reply.

[support]

Hi,

This might be caused by changes to some mbed components. Please try opening VisualGDB Project Properties on the first page and then either change the MCU forth and back, or click “Regenerate MCU-specific files”. This should automatically update all project properties and remove any deprecated settings.

[support]

Hi,

 

The sample projects like “LwIP_HTTP_Server_Netconn_RTOS” come from the ST examples, so if the original example is written in C, VisualGDB will not automatically change it to C++, as simply renaming files may introduce build errors.

There are quite a few things to watch for when converting Plain C code to C++ (the most notorious one is extern “C”), however as this is a generic C/C++ development question and is not specific to VisualGDB, we cannot provide step-by-step instructions for converting each sample. That said, such a conversion is a very commonly performed task, so searching resources like StackOverflow for the errors you encounter will most likely give you detailed answers from other users that performed a similar conversion.

[support]

Hi,

No problem, please find the answers below:

1. If you are not using the Custom edition, you can only have 1 version of the SDK installed at once. It doesn’t have to be the latest version from our servers, but it has to be the same version for all the projects. If you want to use multiple versions without upgrading to the Custom edition, you can simply rename the BSP folder and edit the ID in the BSP.XML file – VisualGDB will then treat it as a separate BSP. You can then switch projects between different versions of the SDK by editing the BSP ID in the nrf5x.xml file.
2. The “shared files location” points to a directory of the VisualGDB-supplied BSP package. It is generated from the original SDK and includes fixes necessary for the project to build out-of-the-box (e.g. patches to linker scripts that allow including the softdevice into the main project binary). You can download BSP packages generated from older SDKs here and install them via VisualGDB Package Manager, however using the raw SDK itself won’t work as it will not include the necessary patches. Our tool for generating the packages from the original SDK is open-source through, so you can experiment with it if you want to support some specific version of the SDK (note that SDK 15.0 support is currently in development and is close to being released).
3. The Embedded Frameworks is a convenient way to add sources and include directories from various nRF5x components to the project. It doesn’t edit the configuration file and only affects the list of source files, include directories and sometimes preprocessor macros. You can find out what exactly each framework does by locating the <EmbeddedFramework> element in BSP.XML, however for Nordic devices the frameworks are just convenience wrappers around the corresponding directories in the SDK.

[support]

Hi,

We are not aware of this issue, so it might be caused by some project-specific configuration (e.g. mismatch between the project and the ESP-IDF version). Normally the ESP-IDF configuration entries are handled by the ESP-IDF itself, so VisualGDB should not change the related logic.

Does the issue happen for any newly created project, some newly created projects, or a specific project you are trying to import? If it is limited to a specific project, does the error also happen when building it from command line?

[support]

Hi,

This is already supported (using the same semantics as PuTTY) – any text selected in the console is automatically copied to the Clipboard and you can paste text via Shift+Insert or via middle mouse button click.

[support]

Hi,

Yes, we have added a new command-line option to VisualGDB to export test results in the VSTest format to this build. Please use the following command line:

VisualGDB.exe /runtests <settings file> /vsoutput:<file.trx>

Then publish it using the regular “Publish Test Results” task (ensure you select the VSTest format). Let us know if you have any feedback/suggestions.

[Author]

Posts