support

Forum Replies Created

Viewing 15 posts - 1,306 through 1,320 (of 7,824 total)
  • Author
    Posts
  • in reply to: VisualGDB Build Window can't open file #31159
    support
    Keymaster

    Hi,

    This would happen if the project contained manually defined path mappings that would map correct paths into incorrect ones.

    Please try resetting mappings via VisualGDB Project Properties -> Path Mapping.

    If it doesn’t help, please try reproducing the problem on a project created from scratch. You can simulate the build output by overriding the build command with “cmd /c type $(ProjectDir)\log.txt” where log.txt is a text file containing the previously captured log.

    support
    Keymaster

    Hi,

    Indeed, the Arduino projects do not have the GUI for changing the hardware register definition file. However, you can always roll it back by removing the MCUDefinitionFile element from the .vgdbproj file, and reloading the project.

    We also advise checking in your project into source control, so that you could track the changes and easily roll them back in case something breaks.

    support
    Keymaster

    Hi,

    The latest v5.6 Beta 4 should work just fine (other than a glitch with VS2022 Preview 2). If not, please try the latest development build: VisualGDB-5.6.5.4280.msi

    If it doesn’t help either, please let us know more details and we will help you get it working.

    in reply to: Sysroot synchronization fails on Pi 4 #31141
    support
    Keymaster

    No problem. SysprogsSync is faster and more efficient than tar or rsync, as it only downloads the mismatching files and also handles complex symbolic links correctly. However, if it doesn’t work, VisualGDB can always fall back to the legacy mechanisms.

    If using tar gets the folder synchronized correctly and using SysprogsSync doesn’t, we can help you get it to work as well, as long as you can provide more details. I.e.:

    1. Specific files that got synchronized with tar and did not get synchronized with SysprogsSync.
    2. A relevant SysprogsSync.log file so that we could recheck whether they were read correctly.
    3. Any relevant details about these files (e.g. they are inside another mounted volume or have special access rights).
    in reply to: analyzer2go-stm32h745zi-q #31139
    support
    Keymaster

    Sorry, we do not support it yet. However, we do support the Nucleo-H743ZI board.

    in reply to: Debugging stand alone project via OpenOCD(STM32MP1) #31138
    support
    Keymaster

    Sorry about that, it was a typo. Indeed, the file is called edp.xml and not bsp.xml.

    in reply to: Debugging stand alone project via OpenOCD(STM32MP1) #31129
    support
    Keymaster

    Hi,

    Thanks for the detailed repro steps. Indeed, the STM32MP1 fork of OpenOCD is designed to not be displayed for regular projects in order to avoid confusion.

    You can work around it by removing the BSPFilter element in the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd.stm32mp1\bsp.xml file and restarting Visual Studio.

    in reply to: VisualGDB Build Window steals focus #31128
    support
    Keymaster

    Hi,

    Please try restarting Visual Studio. If it doesn’t help, you can disable the advanced build window completely via Tools->Options->VisualGDB->Advanced Build->Show build output from VisualGDB projects in = Regular Build Window.

    in reply to: Sysroot synchronization fails on Pi 4 #31118
    support
    Keymaster

    No problem. Please try disabling SysprogsSync for this host via Tools->VisualGDB->SSH Host Manager. This will revert to using tar.

    support
    Keymaster

    Hi,

    No problem and thanks for checking this. We can add the changes on our side if we can confirm that this affects multiple devices and is not a side effect of some very rare condition (e.g. a bug in gcc/gdb).

    If you could reproduce the issue on a simple project created from scratch, please feel free to attach it, and we will try to run a few experiments on it to understand whether it can affect other scenarios. If not, please consider simply patching the framework on your side. You can fork the framework internally (change its ID in the EFP.xml file and move it to a different subdirectory) if you would like to avoid having your changes overwritten by an update.

    in reply to: Sysroot synchronization fails on Pi 4 #31112
    support
    Keymaster

    Thanks, it looks like the synchronization has completed succesfully (other than the warnings). It is hard to say what would cause the error messages, but it should be safe to ignore it, or simply disable SysprogsSync for that host.

    in reply to: Sysroot synchronization fails on Pi 4 #31108
    support
    Keymaster

    Hi,

    No problem. Due to security considerations, the forum engine we are using rejects certain types of attachments. Please try packing the log file into a .7z or a .zip file to work around it.

    Either way, we have updated our toolchain to the latest 2021-05-07-raspios-buster image. The only difference from the previous toolchain release is the contents of the sysroot folder.

    We could not reproduce any issues with synchronizing sysroot, so it could be an indication of network errors or SD card corruption. Either way, please consider using the latest SD card image, or disabling SysprogsSync via Tools->VisualGDB->SSH Host Manager.

    support
    Keymaster

    Hi,

    No problem. Normally, GCC should keep the arguments of SysprogsTestHook_SelectTests() visible even with optimization turned on. Either way, could you please try checking if declaring the function arguments volatile instead of creating extra global variables works as well?

    void __attribute__((noinline)) SysprogsTestHook_SelectTests(volatile int testCount, volatile void **pTests)
    {
        asm("nop");
    }

    If not, please try adding the following line after asm(“nop”):

    volatile int unused = testCount + (int)pTests;

    Does this fix the evaluation of the function arguments?

    • This reply was modified 3 years, 11 months ago by support.
    support
    Keymaster

    Thanks, this makes sense.VisualGDB resets XSCT PATH to avoid conflicts with other tools, and indeed, in this case it would prevent XSCT from running.

    We have published detailed troubleshooting instructions for XSCT issues (including the steps for overriding PATH) here: https://visualgdb.com/documentation/xilinx/xsct.

    in reply to: nRF Connect SDK 1.6.1 Support #31103
    support
    Keymaster

    Hi,

    Yes, please try updating to VisualGDB 5.6 Beta 4. The internals of the nRFConnect SDK have recently changed, so older VisualGDB versions won’t work with it.

Viewing 15 posts - 1,306 through 1,320 (of 7,824 total)