support

Forum Replies Created

Viewing 15 posts - 361 through 375 (of 7,664 total)
  • Author
    Posts
  • in reply to: STLINK-V3MINIE Not Detected #34279
    support
    Keymaster

    Hi,

    Updating VisualGDB version should not affect this because the low-level ST-Link interaction is handled directly by OpenOCD (open-source tool with ST-Link support contributed by ST). If your ST-Link revision is new, it may not be supported by mainline OpenOCD yet.

    You can troubleshoot it as shown below:

    1. Make sure this ST-Link works with STM32CubeIDE (Eclipse-based IDE from Eclipse that also uses OpenOCD).
    2. In VisualGDB Project Properties -> Debug Settings select “OpenOCD (ST Fork)”. This will use a version of OpenOCD equivalent to the one in STM32CubeIDE.

    If the ST fork still doesn’t work with VisualGDB, the STM32CubeMX might be passing different arguments to OpenOCD in this case. Please feel free to share the OpenOCD command lines by STM32CubeIDE and VisualGDB, and we will help you understand/mitigate the differences.

     

    in reply to: Linker Error I don't understand. #34254
    support
    Keymaster

    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.

    in reply to: Custom Build Steps #34249
    support
    Keymaster

    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.

    in reply to: Custom Build Steps #34246
    support
    Keymaster

    Hi,

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

    in reply to: Keil project import with errors #34244
    support
    Keymaster

    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.

     

    in reply to: extremly slow compiling #34240
    support
    Keymaster

    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.

    in reply to: STM32CubeMX generated .S files #34236
    support
    Keymaster

    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

    in reply to: SYSRQ Issue #34235
    support
    Keymaster

    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.

    in reply to: SYSRQ Issue #34233
    support
    Keymaster

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

    in reply to: SYSRQ Issue #34226
    support
    Keymaster

    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.
    in reply to: Code coverage in 'Shared Item Projects' (VS2022) #34222
    support
    Keymaster

    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.

    in reply to: CMake-based unit tests vs. VS Test Explorer #34221
    support
    Keymaster

    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.

    in reply to: Problem using PicoProbe/OpenOCD in VisualGDB #34220
    support
    Keymaster

    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
    Keymaster

    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.

    in reply to: STM32 Library strip #34200
    support
    Keymaster

    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.

Viewing 15 posts - 361 through 375 (of 7,664 total)