support

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 7,192 total)
  • Author
    Posts
  • in reply to: Can't change Raspberry Pi Pico SDK #33756

    support
    Keymaster

    Hi,

    No problem, we have fixed the issue in the following build:  VisualGDB-5.6.109.4809.msi

    in reply to: Visual Studio Crashes when Debugger Stops #33755

    support
    Keymaster

    No worries and thanks for the update. If resetting the repository solved the issue, it was likely caused by corrupt VS-level or VisualGDB-level cache (although VisualGDB-level issues are usually visible on the call stack).

    Either way, if you weird intermittent behavior again, you can simply try deleting the .vs and .visualgdb subdirectories – it should have the same effect as re-cloning the repository, but you won’t need to do a full rebuild.

    in reply to: VisualGDB 5.6 Clean And Source line Build Fail connection #33753

    support
    Keymaster

    Hi,

    Thanks for clarifying this. The “$(ProjectDirLinux)6731_OMFV”  path suggestion is definitely wrong. It is likely suggested because VisualGDB checks the variable list before ProjectDirLinux gets assigned (and hence defaults to an empty value). We have added an extra check on our side to avoid suggesting empty variables in paths, although manually replacing the path with /6731_OMV should work.

    Either way, we have double-checked the screenshots you provided and found a few inconsistencies:

    1. The project path on the Windows machine is n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsc_cmp\projects\rdp.vcxproj. The corresponding project directory on Linux should be /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsc_cmp/projects.
    2. The Linux path of bit.cpp you mentioned is /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsg_cmp/src/bit.cpp.
    3. The relative path reported by gcc is ../src/bit/bit.cpp. Given the base directory, it should translate to /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsc_cmp/src/bit/bit.cpp, that doesn’t match the path in the previous step.
    4. The Windows path computed by VisualGDB when you tried navigating to the file was n:\6731_omfv\SHMUEL\tdp_develop-linux_test\tdp\dsg_cmp\src\bit.cpp. The _test part should not be coming from the project settings shown on the screenshot.

    Our best guess is that you have multiple projects that use slightly different (although confusingly similar) file names, so you are changing the setting for one project, while building a different project. Hence, the settings in the VisualGDB Project Properties do not appear to take effect.

    The easiest way to unwind this would be to remove all projects but one from Solution Explorer, get it working for just one project, and then add the rest of the projects back, one half at a time, and verifying that paths still work. Another option would be to to follow the inconsistencies we pointed out (e.g.the extra /bit part and the _test part). They must be coming from some setting in a different project, and searching the project/settings files for these parts might explain what is going on.

    in reply to: VisualGDB 5.6 Clean And Source line Build Fail connection #33747

    support
    Keymaster

    Hi,

    No problem, we will clarify.

    The variable $(ProjectDirLinux) was created because i understood that Local directory (windows) and Remote directory (Linux) should point to the same directory where the project file is located.
    Since i have $(ProjectDir) that defines automatically the project path to windows and i don’t have such variable for Linux, so i had to create $(ProjectDirLinux).

    It generally depends on how you created $(ProjectDirLinux). You mentioned environment variable, so we assumed it’s something defined in Windows environment (configured via Control Panel->System Settings), that would be the same for all projects. If you defined it as a custom per-project variable, it should be fine.

    You wrote “the contents of its directory will be copied to $(ProjectDirLinux)” i guess you meant the compiler output (such as obj files)

    We meant that according to the last screenshot from your previous post, VisualGDB will copy the *.cpp; *.h; *.hpp; <…> files from $(ProjectDir) to $(ProjectDirLinux) for every project that targets MRS-RDP-LINUX. Depending on how ProjectDirLinux is defined, this may work as expected, or may not work at all.

    Either way, you mentioned the following paths of the file:

    • Windows path: n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsg_cmp\src\bit.cpp
    • Linux path: /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsg_cmp/src/bit.cpp

    You should be able to get everything working by going to the Path Mappings page of VisualGDB Project Properties for rdp.vcxproj and adding the following mapping:

    • Windows path: n:\6731_omfv
    • Linux path: /6731_omfv

    It should cover all the files inside /6731_omfv. You do not need the entry on the Synchronized Directories page, or any other entry. This entry alone should be sufficient to cover all paths.


    support
    Keymaster

    Thanks for your update. We understand that you do not wish to follow our instructions for separating the STM32CubeMX-specific part of the issue from the VisualGDB-specific part. As we have explained before, will not be able to do it for you as a part of our technical support, even if you renew your license. Please consider finding someone else who would agree to help you on your terms.


    support
    Keymaster

    Hi,

    We do not want to cause any misunderstanding with your renewal and would like to make sure the issue is actually caused by VisualGDB. Please follow the steps from our previous reply and make sure you can find a specific parameter that did not get imported by VisualGDB.

    If you cannot narrow this down to a specific parameter, it is likely caused by a bug in STM32CubeMX generator, or one of the libraries you are using, and we will not be able to fix it even if you renew your support.

    in reply to: How to prevent Visual Studio recompiling whole project #33739

    support
    Keymaster

    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.

    Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

    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

    Please refer to this page for a detailed explanation of the technical support scope.

    Specifically in this case, we can fix it if you are able to:

    1. Build the same project using a different IDE (e.g. STM32CubeIDE).
    2. Compare the broken project against working project and point out a specific file, or a specific setting that did not get imported by VisualGDB.
    3. Confirm that the project file imported by VisualGDB clearly references the file or contains the setting isolated on the previous step (i.e. the issue is with the VisualGDB importer and not the project).

    If do not wish to do it and would like us to analyze a non-trivial broken project and find the root cause, we can gladly do it at our consulting rate.

    You can find a detailed comparison of different VisualGDB editions here.

     


    support
    Keymaster

    Hi,

    It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey

    in reply to: STM32MP1 SDK Build #33729

    support
    Keymaster

    Hi,

    In our experience, it is possible with some trial-and-error. We ended up hijacking the configuration command lines for binutils/gcc/gdb, manually patching them to produce a Windows toolchain, manually running them and resolving the issues that arose. If you wish, we can do it for your custom module for a fixed price. We would need your existing VM with the regular toolchain build environment; we will edit it to produce a Win32 toolchain, and will document the steps needed to fix everything. Feel free to reach out to our sales if you would like to get a quote.

    in reply to: Help to edit pertition table flash into memory #33728

    support
    Keymaster

    Hi,

    Most likely, the project you imported defines something incorrectly. If you would like us to investigate it and pinpoint the root cause, we can gladly do it at our consulting rate.

    If you believe it is a VisualGDB issue, please make sure you can reproduce it on a newly project created from scratch per our problem reporting guidelines. If the problem only happens with a specific 3rd-party project, it is likely caused by invalid settings somewhere in that project.

    in reply to: CPU frequency missing in project configuration #33716

    support
    Keymaster

    Hi,

    No problem,we have rechecked it. Indeed, Espressif has moved the definition of the CPU-specific settings in a way that VisualGDB couldn’t properly parse. We have updated VisualGDB to handle it properly: VisualGDB-5.6.109.4807.msi

    in reply to: External ESP-IDF components #33714

    support
    Keymaster

    Hi,

    For ESP-IDF projects, VisualGDB works as a front-end to the regular ESP-IDF build system. I.e. it provides convenient GUI for managing common ESP-IDF settings and tasks, but lets the normal ESP-IDF build scripts handle all the building. E.g. when you add a file to Solution Explorer, VisualGDB would update the idf_component_register() in CMakeLists.txt, but will still let the ESP-IDF handle the actual build, as if you edited the statement manually.

    There is no special GUI setting for importing external components made for ESP-IDF 4.4.1 and automatically porting them to work with ESP-IDF 5.0. You would need to manually add them to the project by editing the relevant CMakelists.txt files (see the ESP-IDF documentation for specific instructions), and possibly porting them to the new ESP-IDF 5.0. VisualGDB cannot do this work automatically, but it can make it easier by providing powerful IntelliSense and debugging functionality that will help you navigate the unknown code base faster.

     

    in reply to: CPU frequency missing in project configuration #33713

    support
    Keymaster

    The sdkconfig file contains the values of the parameters, but not their descriptions. The actual descriptions are stored in the KConfig files scattered across the ESP-IDF folder. VisualGDB parses them, combines the result in a convenient searchable tree, fills it with values from sdkconfig and displays it on the first page of VisualGDB Project Properties.

    Different ESP-IDF versions can have slightly different setting layouts (e.g. a the same setting could be called differently) and VisualGDB Project Properties would reflect it.

    We can double-check the CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ setting on ESP-IDF 5 if you could share a screenshot of your Help->About VisualGDB window to make sure we are looking at the same thing.

    in reply to: Visual Studio Crashes when Debugger Stops #33706

    support
    Keymaster

    If the inner VS instance crashes without reporting anything to the outer one, you have likely selected an incorrect debug engine when attaching the outer VS instance to it.

    Please try selecting both “Native” and “Managed (.Net 4.x)” as the debug engines in the Attach dialog. This should catch crashes caused by both managed and native code.

Viewing 15 posts - 16 through 30 (of 7,192 total)