[support]

Hi,

No problem, please see this thread for a detailed explanation and a few workarounds.

[support]

Hi,

Good to know it works.

We haven’t specifically tested VisualGDB with FuSa components, however based on the first impression, they look like certified versions of the usual Keil components, so VisualGDB should work with them just fine.

If you encounter any issues, feel free to post the details, and we will do our best to help you.

If you wish, we can also test everything on our side and deliver a ready-to-use development environment with tutorials covering the topics of your interest as a part of our customization services.

 

[support]

Hi,

Does the build produce a lot of output, particularly very long lines? If yes, could you please attach the raw output (from running the .bat file with output redirection)?

Also, could you double-check that Visual Studio doesn’t show any errors about the VisualGDBNative module when you open the project for the first time? It implements a few optimizations, namely a fast regex parser used for build message translation.

[support]

Hi,

We are aware that the STM32CubeMX generates the assembly files with the lowercase extension, but so far, the examples we’ve seen did not depend on the preprocessor. It makes sense that AzureRTOS would handle it differently.

We have updated VisualGDB to automatically rename the files on importing. Please try this build: VisualGDB-5.6.109.4864.msi

[support]

Hi,

This looks like the new kernel has a slightly different configuration (has function tracing API enabled), but is using the older API. Either way, we have updated VisualKernel to handle it correctly: VisualKernel-4.0.101.2374.msi

The new build also fixes the 3-machine issues you described earlier, and improves tracing of inline functions.

[support]

Hi,

Oops, sorry about the trace data window glitch. It was a side effect of another last-minute fix. Please try this build: VisualKernel-4.0.101.2372.msi

It also fixes the in-code tracepoint links for inline functions and functions with discontiguous ranges (they were previously traceable via the New Tracpoint button, but not via code).

[support]

Hi,

No problem. If you saw the actual module count in the GUI (not in the debug logs), it was likely trying to build IntelliSense index, rather than the tracepoint index. If it doesn’t happen anymore, it should be safe to ignore.

With the sysrq issues, the only 2 causes we could think of would be timing and SSH command/interactive mode differences. When VisualKernel runs commands over SSH, it uses the special command mode (same as running “ssh user@host <command>” from another Linux machine, but slightly different from running commands directly.

You can try narrowing it down as follows:

1. Extract the exact commands used by VisualKernel from the diagnostic log. You can filter out the spammy “stat” commands by using negative grep (grep -v -e “stat” < log1.txt > log2.txt).
2. Try running them via ssh from another Linux machine to replicate the SSH command mode used by VisualGDB.
3. If it doesn’t reproduce the problem, try renaming the related executables (e.g. /usr/bin/echo => /usr/bin/echo2) and replacing them with wrapper scripts that will introduce ~5 second delays. This should eliminate issues due to timing.

With tracing, please try this build: VisualKernel-4.0.101.2371.msi

It fixes a few issues with the symbol parsing logic that were discovered while testing the 6.x kernel, and might fix the issue you described. If not, could you please check:

1. Is the function defined in the kernel itself, or one of the modules? If it is in a module, you would need to add its name to the list of traced modules via VisualKernel Project Properties, or Quick Debug window (requires new build).
2. Does the function appear in the list when you click the “new tracepoint” button in the Tracepoints window?
3. Can you set tracepoints there via the tracepoint bar (see below)?

We will look into supporting tracing for remote kernels and will publish a hotfix here in a few more days.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Both Synchronized Directories and pre-build steps should work fine.

If it doesn’t work, please make sure you can simplify the problem to a project that can be created from scratch and then provide the steps to reproduce it:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch. See this page for more information and detailed examples.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

As long as you provide the full repro steps, we should be able to point out the setting that is causing it, or provide you with a hotfix if necessary.

[support]

Hi,

CMake-based tests should work just fine. Most likely, some of the settings you specified are preventing them from working.

We can help you get it working if you could share the steps to reproduce the problem from scratch:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch. See this page for more information and detailed examples.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

[support]

Hi,

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch. See this page for more information and detailed examples.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

[support]

Hi,

Most likely, you have enabled the Tools->Options->VisualGDB->General->Debug->Remember Quick Debug Sources setting, so VisualGDB keeps reopening the previously open files.

If this is not intended, please consider disabling the setting.

[support]

Hi,

You can try running the strip tool from the ARM toolchain:

arm-none-eabi-strip.exe <Library file>

If you would like to do it automatically, you can add it to VisualGDB Project Properties -> Custom Build Steps -> Post-Build Steps.

[support]

Hi,

Indeed, this should work. You can edit this setting via GUI by selecting the BSP in Solution Explorer and opening its properties. See this page for a detailed overview of the embedded CMake projects and various options that can be edited.

[support]

Hi,

The project importing logic can automatically handle the most common settings (device type, list of sources/headers, include directories, preprocessor macros, libraries, scatter file). If your project is considerably more complex, it may indeed require manual adjustment after importing.

There are 2 ways to address it:

• You can try creating a new project from scratch as shown in this tutorial, and compare it against the broken one.
• You can try following this tutorial to compare the build command lines between the original Keil project and the imported project.

If you prefer, we can compare the projects for you over a screen sharing session, and fix all the issues, however we would have to charge our consulting rate for it, since it is not something that can be done fully automatically.

[support]

Hi,

Sorry about that. The ftrace_ops error looks like our previous fix was incomplete. It’s not about the kernel version, but rather about the kernel being built without ftrace. We have fixed it in this build: VisualKernel-4.0.101.2367.msi

The issue with the list of functions is different – most likely your custom kernel uses some parameters that confuse some of the VisualKernel’s parsing logic. We have tested it against several different platforms and kernel versions, but never encountered this error. Would you be able to share your vmlinux file with us so that we could retest it on our side? If not we can add some extra logging to pinpoint the root cause, but it would take longer. For what it’s worth, you can also try hitting “cancel” after most modules within the kernel have been indexed – VisualKernel with proceed with what it indexed so far, allowing you to set tracepoints there.

Also with performance, the initial indexing could indeed take long (takes about a minute on i9-12900KS), however once it is done, VisualKernel saves the indexed symbols in its own optimized format, and loads them next time almost instantaneously.

With KDB, VisualKernel just runs this command line as root:

sh -c -"echo g > /proc/sysrq-trigger"

If you are triggering sysrq differently, please let us know. You can also try checking VisualKernel Diagnostics Console (you may need to grep the log for SSH). It shows all SSH commands issued by VisualKernel, so you can always compare them against the manual list. But if the version without KDB works, it could be indeed an easier solution.

Edit: the traceable symbol indexing should not normally show the number of processed files unless you are looking into the debug view. Are you sure you did not accidentally start IntelliSense indexing instead (e.g. via CodeJumps)?

• This reply was modified 2 years, 2 months ago by support.

[Author]

Posts