[support]

Hi,

The GNU linker indeed has a few quirks that could be somewhat confusing. A good starting point would be this page that explains the differences between different input types, and also suggests how to obtain extra diagnostic output.

[support]

Hi,

No worries, the files are very intuitive and straight-forward. You can create new files or reference existing files via the action list editors, and then drag-and-drop actions between the regular lists and the shared files. Any settings file (with any combination of action lists) can reference an arbitrary amount of shared lists with optional conditions.

If you encounter any issues, feel free to get back to us and we will help.

[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.

[Author]

Posts