[support]

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

[support]

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

[support]

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

[support]

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.

[support]

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.

[support]

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

[support]

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.

[support]

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.

[support]

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]

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 4 years, 5 months ago by support.

[support]

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.

[support]

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.

[support]

Hi,

This error means that the remote SysprogsSync executable, that packs the remote file system, handling filters and up-to-date files, exited unexpectedly. It is likely a bug in SysprogsSync triggered by something very specific on that particular SD card image.

You can try enabling SysprogsSync logging (Tools->Options->VisualGDB->General->SSH->Log SysprogsSync Transfers) and checking the SysprogsSync.log file in the Windows sysroot directory to get an idea of what is going on, or simply disable SysprogsSync for this target via Tools->VisualGDB->SSH Host Manager.

That said, if you are using a completely different SD card image, the existing toolchain will likely not work with it, or may produce unexpected results, even if you resynchronize sysroot. If you are using a custom tool to generate the image, it might have a special mode to build a cross-toolchain as well. Even if the target cross-toolchain runs on Linux, VisualGDB can still use it via an additional Linux VM or WSL.

[support]

This means that indeed xsct fails to start when launched from VisualGDB. As it runs successfully from the other window, it is likely caused by some environment variables inherited from VS. Comparing the environments between the 2 command prompt windows as we described before should help find the root cause.

[support]

This looks like xsct.bat indeed exits immediately after starting, so you are entering the xsdbserver command into the Windows command prompt instead of the XSCT command prompt.

Please try running the XSCT command (<…>\xsct.bat -n -interactive) in the command prompt window. If it doesn’t start XSCT successfully, please try comparing the PATH variable in that window vs. in a newly opened command prompt window, and then adjusting it manually to see if it fixes XSCT. If you can point to a specific component of PATH (or any other variable) that fixes the problem, we can gladly update VisualGDB to detect and fix this automatically.

[Author]

Posts