support

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 7,067 total)
  • Author
    Posts
  • in reply to: This target type does not support running QuickSync requests #33203

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

    Hi,

    This would be fairly straight forward for the regular CMake projects, since CMake supports multiple applications/libraries in the same project out-of-the-box. However, the use of ESP-IDF makes things more complicated, since it implicitly expects a project to have one primary application referencing multiple components.

    We would advise researching how ESP-IDF internally defines the bootloader targets, since the bootloader is essentially a separate mini-application built within the same project. You might be able to reuse some of that logic to build the application for the FACTORY partition. That said, it might require patching ESP-IDF or might rely on some APIs that will be changed in future versions. It is ultimately something to do at your own risk.

    in reply to: R7FA4M2AD3CFP Default LED project #33198

    support
    Keymaster

    Hi,

    Thanks for pointing this out. The Renesas devices are quite different from other device families supported by VisualGDB. They extensively rely on fairly complex code generation logic (that uses JavaScript in some cases). VisualGDB does not include a JavaScript engine and cannot replicate the original logic with 100% accuracy, however it still supports a reasonable subset of it that can still save time, while requiring occasional manual adjustments.

    In this case, the incorrect syntax comes from the following line in the BSP.XML file:

    You can work around it by patching the file as follows:

    You can then set BPS0 to 0 via the project properties (or just hardcode 0 in the template instead of $$config.bsp.fsp.BPS.BPS0$$).

    We have noted this in our roadmap for the Renesas BSP, and will look further into it when releasing the next BSP version.

    in reply to: Remote debugging with custom GDB stub #33197

    support
    Keymaster

    Thanks for the detailed video. Indeed, the logic for automatically stripping the SSH port worked for the Linux projects, but not for the embedded projects (building the project locally while debugging it with a remote stub running on a target with a custom SSH port is an extremely rare scenario).

    We have fixed it in the following build: VisualGDB-5.6.108.4714.msi

    in reply to: CMake target shema with multiple targets #33196

    support
    Keymaster

    Thanks, we have reproduced the issue and fixed it in the following build: VisualGDB-5.6.108.4714.msi


    support
    Keymaster

    Hi,

    Just wanted to let you know that we have just released VisualKernel 4.0 Beta 2.

    It includes the fix for the LinuxKernelDebugHelper build issue you mentioned, has numerous stability improvements and fixes the issue with the module list filter.

    Regarding the extra component in the module path (C:\Users\<username>\source\repos\vmware-ubuntu-16.04\vmware-ubuntu-16.04\vmware-ubuntu-16.04\drivers\media\usb\dvb-usb), VisualKernel computes them using the following logic:

    1. Locates the kernel release under your kernel release directory (configurable via Tools->VisualKernel->Manage Linux Kernel Symbols).
    2. Loads the matching IndexedModules/InTreeKernelModule element in KernelRelease.xml and appends the PathRelativetoKernel value to the directory of the KernelRelease.xml file.

    If you consistently get invalid paths, could you please recheck what module paths are stored in KernelRelease.xml? If they contain an extra component, please try patching the file manually, or just re-importing the kernel using the kernel symbol manager. This should get the correct paths stored, so VisualKernel will be able to load them automatically.

     

    in reply to: CubeMX + FreeRTOS + VisualGDB problem #33194

    support
    Keymaster

    The original issue has been resolved a long time ago, so this is likely something different.

    Generally, STM32CubeMX sometimes misses some sources or headers when generating project templates. Newer versions of STM32CubeMX often fix such issues, but sometimes introduce new cases.

    The best idea to troubleshoot it is to specifically look for header files defining the missing symbols, and then trace it down:

    1. Is the header file included via #include<>?
    2. If yes, but the header file is not found, does the include search path contain the header file’s directory?
    3. Are the definitions conditional to a #define that is not defined?

    If you can narrow it down to a specific construct in the generated STM32CubeMX file that was not imported correctly, we should be able to fix the importing logic to handle it properly. If not, please consider editing the sources manually to include the necessary parts.

    in reply to: Targeting a new embedded Linux board? #33190

    support
    Keymaster

    We do provide toolchains for the most common targets (Raspberry Pi, STM32MP1) free of charge.

    If you believe that Variscite should be sponsoring a toolchain for their target, feel free to contact them and convince them to do so. We are fine either way, as long as someone agrees to cover the research, porting and testing costs.

    in reply to: Targeting a new embedded Linux board? #33188

    support
    Keymaster

    Hi,

    The embedded toolchains usually need to be individually built for each specific target. The exact steps vary from distribution to distribution, and often involve troubleshooting some unexpected weird issues, so there is no common guidance here. E.g. we recently updated our STM32MP1 toolchain and had to resolve compatibility issues between the yocto-specific gdb patches and the MinGW toolchain, and also encountered a bug that ware interfering with multi-threaded builds.

    You can indeed try using a similar toolchain (e.g. Raspberry Pi), but it may trigger further weird issues when you try to use it for complex projects. It really depends on the differences between the platforms and there’s no fully automatic solution here.

    We do offer a toolchain building service for custom targets, so if you start running into strange problems that take too much time to solve, feel free to contact our sales for a quote.

    in reply to: Test Explorer with VisualGDB 5.6r8 #33179

    support
    Keymaster

    Hi,

    Sorry for the confusion, this is actually by design. One of our customers uses a large solution with multiple test projects to cover several hardware platforms. They use the “build” flag in the Configuration Manager to specify which test projects should be built for each platform, so the previous behavior (showing unit tests from all projects, even if they are excluded from build for the current configuration) was showing a lot of irrelevant tests.

    As it looked like a very specific and rare scenario, we did not add a separate setting for this behavior.

    If your setup relies on the old behavior (i.e. the projects were not excluded from build by mistake), we can gladly add a setting controlling whether to show the tests from the unit test projects that are not built.

    Attachments:
    You must be logged in to view attached files.
    in reply to: Gdb session error #33177

    support
    Keymaster

    According to our records, your trial has expired, hence VisualKernel stopped working. If you would like to get technical support, please consider purchasing a license and make sure you use an unmodified VisuaKernel installer. Please note that creating a new email address and a forum account does not automatically grant additional technical support.

    in reply to: Gdb session error #33175

    support
    Keymaster

    Hi,

    Please make sure you use an unmodified installer of VisualKernel downloaded from our website.

    If it still doesn’t work, please let us know the email address associated with your license key so that we could check your support status.


    support
    Keymaster

    Hi,

    No problem, we can help you. The build errors happen because the LiveMemoryEngine.c file (responsible for the new Live Watch feature) cannot find the definitions of kthread_should_stop(), kthread_run() and kthread_stop() functions. The functions are defined in the kthread.h file that should normally be included from one of the headers already referenced from Live MemoryEngine.c, however it may be different in the kernel version you are using.

    Do you mind adding #include <linux/kthread.h> to LiveMemoryEngine.c manually and trying to debug again? If this solves the problem, we will update it on our side.

    Regarding the .ko file issue, could you please clarify how is the file referenced? Is it one of the modules indexed together with the kernel release, or are you building it manually? Also if you could attach the relevant .vkrnlproj/KernelRelease.xml files, we should be able to pinpoint the issue faster.


    support
    Keymaster

    You can if you follow the steps outlined in the documentation and tutorials. If you are doing something different from the steps suggested in the documentation, you will inevitably get different results.

    We have asked you to provide the steps to reproduce the issue beginning from VS launch, accompanied by the uncropped screenshots, so that we could point out what you are doing incorrectly. Instead, you have provided ambiguous steps and attached 3 instances of the same cropped screenshot that does not show sufficient context.

    We will not be able to help you based on the information you provided and have to close the issue. If you require further help, please do read and follow our problem reporting guidelines. We will not be able to provide any further replies unless you provide the information we requested.


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

    • This reply was modified 2 weeks, 5 days ago by  support.
Viewing 15 posts - 16 through 30 (of 7,067 total)