[support]

Hi,

Thanks for the component.mk file. Please also let us know the full path of a header file that is not shown and share the entire output from the VisualGDB Diagnostics Console.

[support]

Hi,

No worries. This is actually a known issue of gcc (e.g. see this discussion). Generally, though, we advise avoiding non-static inline functions, as they could cause hard-to-diagnose problems in large projects where multiple source files define different versions of an inline function with the same name.

E.g. if file1.cpp defines inline void memset32(void *, int, int numberOfWords) and file2.cpp defines inline void memset32(void *, int, int numberOfBytes), the debug build (with inlining disabled) may silently replace one of the implementations with another one, as both functions will get compiled as weak global symbols. Declaring inline functions as static limits them to the declaring translation unit, fully avoiding this issue and also resolving the problem you encountered.

[support]

Hi,

Sorry, we don’t have a specific import plugin for Infineon DAVE, however the regular import mode in the wizard should be a good starting point (you would still need to specify include directories/preprocessor macros manually).

The “redefinition of variables” error most likely happens because the imported project includes a copy of some system files (e.g. peripheral drivers or startup files) that are already included in the VisualGDB project. It could be solved by locating such files and ensuring that you only leave one copy of them (i.e. either remove the one from the imported project, or unreference the corresponding embedded framework via VisualGDB Project Properties). Feel free to post the exact error message here and we can give more specific advice.

[support]

Hi,

Unfortunately that’s a tough one to diagnose. It typically indicates some sort of incompatibility between the libusb library (used by OpenOCD) and your USB controller driver (or some filter driver, e.g. provided by USB virtualization software). As the issue is caused in an external component, and we won’t be able to reproduce it on our side (as it’s specific to a certain USB driver), it’s hard for us to suggest definitive steps for resolving it.

Our general advice would be to try it on a different machine with a different USB controller or to try reinstalling all USB-related drivers (e.g. ST-Link driver, USB controller driver). Another option would be to build our OpenOCD fork from sources (see this tutorial) and try stepping through the USB-related functions. If you are OK going through this process, we can help you find the relevant parts of the OpenOCD code and will include a patch for the issue in our OpenOCD fork we could pinpoint it based on your observations.

P.S. Please double-check that you are using the “USB devices”, not “debug methods” view in VisualGDB Debug Settings, so VisualGDB can check and install the missing drivers. If not, this could be as easy as a missing USB driver for ST-Link.

[support]

Hi,

Could it be that your implementation of _read() was not declared with extern “C” and hence would not replace the original one? We have done a quick test with newlib-nano and scanf() did call the redefined _read(). If nothing helps, please try checking if your version of _read() is actually compiled in (e.g. set a breakpoint in _read by function name and see whether it resolves to your function).

Regarding email notifications, unfortunately we had to disable it some email servers classified those notifications as spam and prevented the delivery of regular emails from our domain as well.

With C++, there are a few cases where it could be beneficial to embedded projects, (e.g. using RAII to avoid “forgot to call release() before return” errors, or using templates as a more IntelliSense- and debugger-friendly alternative to bulky plain C macros), although whether it pays off depends on the project size, style and many other factors. VisualGDB is designed to support both Plain C and C++ projects, so it should provide comfortable development experience for both languages.

[support]

Hi,

Thanks for narrowing it down. It looks like a combination of our language service and the debug engine was indeed causing a rather strange race condition inside the VS editor, that resulted in evaluating the incorrect expression.

We have changed the expression finding logic in a way that no longer triggers the problem in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2406.msi

[support]

Hi,

Yes, GoogleTest uses the <GroupName>_<TestName> syntax for internal test symbol names, so VisualGDB indeed gets confused when the test name itself contains an underscore.

You could work around this by patching the %LOCALAPPDATA%\VisualGDB\TestFrameworks\com.sysprogs.unittest.googletest\TestFramework.xml file as shown below:

<TestIDRegex>([^_]*)_(.*)</TestIDRegex>

However, this will break if the test group names contain underscores. So if it’s possible to avoid underscores in your group/test names, we would advise doing that instead.

[support]

Hi,

OK, please try isolating one specific case of broken IntelliSense (e.g. some variable or function is not found) and check if it’s still related to the mismatching __cplusplus definition, or something else (e.g. missing hardware/software FP macros). If you need more detailed instructions on this, please let us know a specific example of an IntelliSense error and we will help you narrow it down.

[support]

Hi,

Unfortunately it’s hard to pinpoint the source of this without seeing the call stack. Please try checking the test logs and VisualGDB Diagnostics Console for more detailed errors containing a stack trace.

[support]

Hi,

Please double-check that your source files have the .cpp, not .c extension. Even if one .c file included a header file with C++ constructs, it would result in a build error.

[support]

Hi,

Sorry, unfortunately not much. As this kernel version was discontinued ~7 years ago, most modern tools will likely not support it anymore, so we would advise switching to a newer system that runs a 3.x or a 4.x kernel.

[support]

Hi,

Please try exporting your VS color settings via Tools -> Import and Export Settings and then restoring them if the VisualGDB installation resets them.

[support]

Hi,

Thanks for checking this. If the “print” command works, this is likely an issue between VisualGDB and gdb, so we should be able to fix it easily.

Please create a diagnostic gdb log showing the incorrect value obtained via the “watch” window and the correct value for the same variable obtained via the “print” command and we should be able to see what is going on.

[support]

Hi,

Sorry, we don’t support older kernels officially as they are missing many APIs required by various parts of VisualKernel (e.g. our Ethernet debugging driver and the fast module enumeration driver). As we provide source code for both of those components, you might be able to patch them to run under older kernels, but we won’t be officially supporting the 2.4 kernel as it is no longer actively maintained and not used in modern distros.

[support]

Hi,

If you are using the Segger GDB stub, yes, the stub is responsible for reading the ITM-related registers and generating the output stream shown in the Raw Terminal window, hence it’s up to the stub to control the exact output format. Please check with Segger whether there is an option for removing the that. Another option would be to create a basic tool that will work like a proxy server between the gdb stub and the raw terminal, removing the extra symbols (you would need to know where exactly the Segger stub inserts the channel number bytes).

[Author]

Posts