[support]

Hi,

Long-term we are planning to add a tool window (similar to Solution Explorer) that will let you easily browse through files seen by the gdb (with filter). However this feature will not make it into the upcoming v5.4, sorry.

[support]

Hi,

Thanks for clarifying this. Please try clicking the “test connection” button in both cases, copy the OpenOCD command line shown in the test window and then compare the working command line with non-working one. Then please try running OpenOCD manually to determine a specific flag that causes the issue.

[support]

Hi,

In our experiments this worked differently with different JTAG debuggers (e.g. Segger J-Link vs Olimex), so we would advise trying both to see which one works with your device.

[support]

Hi,

No problem, we will try to explain how this works.

Function calls like _write() are the low-level calls used by the standard library to implement basic I/O. E.g. if you call printf(), the library itself will format the text and then will call _write() to actually send out the exact string. VisualGDB projects can have one of the following implementations of those functions:

• Regular semihosting. Selected via the first page of VisualGDB Project Properties and is slower than the advanced semihosting. The output from printf() will appear inside Visual Studio.
• Advanced semihosting. Selected by referencing the corresponding framework via VisualGDB Project Properties -> Embedded Frameworks. Similar to the regular semihosting, but only works with VisualGDB and is much faster than the regular one.
• Any other implementation that is built together with your code (i.e. a .c or .cpp file defining those functions). E.g. it may redirect printf() output to a UART port.

Most likely you have imported some implementation of those functions together with your project, causing conflicts between it and the regular semihosting. To fix this, you need to ensure that only one of the options mentioned above is enabled. One way to do this is to select “none” in VisualGDB Project Properties, another way is to remove syscalls.c from the project. If it looks like syscalls.c was just copied from the standard library and doesn’t add any functionality on top of that, we would suggest removing it to reduce the codebase size. Otherwise, disabling semihosting via VisualGDB Project Properties like you did, is the right way to go.

[support]

Hi,

Sorry, looks like the exception screenshot was not attached properly. Could you please click on “details” and copy the full exception text with the call stack?

[support]

Hi,

If the problem only occurs on your board, but not on the reference board, it is likely caused by wiring issues (e.g. cross-talk, wrong reset connection, etc.). Generally if the problem cannot be reliably reproduced on any of the boards mentioned in our tutorials, we won’t be able to offer much help as a part of our regular product support. That said, feel free to attach the error log you are getting from OpenOCD. If this is something we have seen before, we might be able to at least suggest the direction for further investigation.

[support]

 

Hi,

Please try changing the following option:

Tools->Options->Text Editor->C/C++ (VisualGDB) -> Formatting -> Newline Insertion -> New functions.

[support]

Hi,

Sorry, we only provide support for our products on this forum. For general Qt-related questions please consider creating a thread at the Qt forum.

[support]

Hi,

Please try installing the experimental J-Link package from http://sysprogs.com/files/tmp/segger-dmsp-5.1preview1.vgdbxedp.

You can install it into VisualGDB via Tools->VisualGDB->Manage VisualGDB Packages.

[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

[Author]

Posts