Forum Replies Created
-
Posts
-
The mechanisms used by VisualKernel to manage the modules vary between different Linux kernel versions. To make things more complicated, some of the distros have previously backported some trace-related changes into their kernel fork (so that the same kernel version used by different distros would require a different configuration).
Furthermore, those options are also different between hardware platforms, hence a configuration that works for one distro/kernel versions will very likely not work with others (we have previously encountered that).
This is exactly why we chose to support a handful of most popular distros and configurations (i.e. test everything on our side and make sure VisualKernel sets all necessary parameters automatically) and provide sources for all low-level components so that they could be tweaked to target an unsupported configuration.
We understand you are using an unsupported distro and expect the level of support we would normally provide for a supported distro. Unfortunately, this is not something we can offer at a price of an off-the-shelf product, as it is only possible to directly support popular distros/targets that are relevant to many users as the same time.
Sorry, VisualKernel does not support the generic armhf build of Debian as it is not as popular as other distros.
VisualKernel does support the following distros for desktop (x86 and amd64 targets):
- Ubuntu
- Debian
- Mint
- CentOS
- Fedora
See the history page for a list of specific versions supported by a particular VisualKernel release.
VisualKernel also supports the following ARM targets:
Generally, you should be able to target an unsupported distro as well, however you would need to research the compatible flags and settings on your side. As directly supporting each distro requires considerable non-trivial troubleshooting, we are only able to offer out-of-the-box support for a handful of most popular distributions.
Regarding LinuxKernelDebugHelper, we will try to address this in one of the next releases of VisualKernel, however as the issue is only triggered by a specific kernel configuration on an unsupported distro, this has a relatively low priority.
We have quickly rechecked the latest Debian 10.2 and the default kernel shipped with it is built with the CONFIG_KALLSYMS_ALL option.
Most likely, you are using an unsupported Linux distro, that explains the configuration errors. You can find a list of supported distros here: https://visualkernel.com/history/.
If you are not sure, please share the URL to the ISO file you are using and can check if it is supported.Also VisualKernel would normally detect tracepoint issues a compile-time and would not attempt to load LinuxKernelDebugHelper, however if you are using an unsupported distro that was never tested with VisualKernel, this check indeed may not work as expected. Either way, it is highly unlikely that dereferencing a null pointer would replace the kernel version string with random characters, while keeping the system otherwise usable.
This limitation comes from the fact that the native Linux Kernel build system (KBuild) does not natively support separate debug/release build subdirectories, hence supporting Debug/Release builds from the VisualKernel GUI without the risk of combining incompatible files would require non-trivial patches to Kbuild.
Furthermore, in our experience, the release builds of performance-critical modules (e.g. drivers) are usually done as a part of a larger build system (e.g. Yocto), while the VisualKernel projects are used for debug builds.
Since VisualKernel uses unmodified KBuild Makefiles, you can always extend them to use conditional statements (e.g. ifeq()) in order to apply different flags depending on the arguments passed via command line. However, as this presents a risk of combining files built with different flags, it is not supported out-of-the-box and is only recommended for advanced users that are comfortable editing Makefiles.
Hi,
Yes, you should be able to get it working by running OpenOCD on the customer’s machine and setting up TCP port forwarding so that you can connect to it from your lab.
You would need to find out the following parameters used in a regular debug session and replicate them manually with a 2-machine setup:
- The OpenOCD command line. You can find it in the OpenOCD window in Visual Studio (or in the connection testing window when you press the “Test” button in the VisualGDB Project Properties).
- The GDB command line. Is is typically gdb –interpreter mi $(TargetPath).
- The startup gdb commands involved in a regular session (e.g. target remote host:port, load, etc). You can find them out by switching the GDB Session window to “All GDB Interaction” mode.
Once you find out those parameters and can successfully launch OpenOCD remotely, you can use the Debug Settings page of VisualGDB Project Properties to switch the debug method to the “Custom” mode. This will allow entering the gdb command line and startup commands manually, so you can connect to the remote OpenOCD instance.
We would also advise trying to manually launch OpenOCD locally and connect to it using the custom mode first. This should help decouple the manual setup problems from potential network problems.
Sorry, we have reviewed the differences between the STM8 devices and other devices. Given that the STM8 devices require a special C-only compiler and are not compatible with most of the tools used by VisualGDB, we have decided to not support them at this time. We may reevaluate this in the future in case the underlying tools improve or the STM8 devices become more mainstream, however currently we have decided to not support STM8 out-of-the-box, sorry.
Hi,
This looks like something on the Visual Studio level and not on VisualGDB level. Please try checking if the same happens for a regular Win32 C++ project that is not based on VisualGDB.
If you can confirm that the problem is specific to VisualGDB projects, we can help you resolve it, however we would kindly ask to renew your support first, as it has currently expired.
Hi,
Sorry, as the STM32 drivers come directly from ST and are not maintained by us, the support we can provide here is somewhat limited.
Please try reproducing the problem with a new project created from scratch (by selecting the “STM32CubeMX Samples” in the wizard). If it persists, please consider submitting a bugreport to ST (you can find the SDK version used by each BSP in the SDKVersions.xml file).
If the problem does not happen on a new project, most likely the new SDK has introduced new configuration parameters, or changed some APIs, and the project would need to be updated accordingly. Comparing the project code with the freshly cloned sample project should be a good starting point.
Hi,
Normally, using the VisualGDB.exe /runtests <container> command line would automatically program the memory, run the tests and save the results.
If you are not using the VisualGDB test frameworks, you can also use the VisualGDB.exe /launch <vgdbsettings file> syntax as an equivalent of the “run without debugging” command in Visual Studio.
Finally, Segger J-Link might have its own set of commands for scripting FLASH memory programming. Feel free to double-check their documentation, it may contain some relevant examples.
Hi,
Please follow the instructions described on this page. They go through the most common causes of this problem.
If nothing helps, please let us know more details (per instructions) and we will help you get it to work.
Hi,
Looks like you are using a VisualGDB edition that does not support hardware tracing.
The J-Trace functionality is supported starting from the Custom edition. You can always upgrade your existing license via this page. If you would like to try it before upgrading, please contact our sales for a trial extension voucher.
No problem, we can help you. Could you please share the screenshots of the Debug Settings page and the Embedded Debug Tweaking pages so that we could look into this?
Hi,
It looks like your machine is missing some packages. Please try updating to VisualGDB 5.5 Preview 2. It will automatically install the missing packages on project load.
Yes, that’s the correct option and thanks for sharing the screenshot. Sorry for being non-specific, we thought suggesting the general direction immediately would be more useful than putting this through the repro queue in order to produce an exact screenshot on our side.
Hi,
Sorry, this is a known limitation of the latest Raspberry Pi toolchain. It no longer supports QMake due to internal changes in the toolchain structure.
Please try updating to VisualGDB 5.5 Preview 2 and creating a Qt-based project as shown here: https://visualgdb.com/tutorials/linux/qt/cmake/
