[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, 10 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.

[support]

No problem. Please try this build: VisualGDB-5.6.5.4263.msi

Please try enabling the Tools->Options->VisualGDB->Xilinx->XSCT Diagnostics Mode option. This will launch XSCT in a separate command prompt window, allowing you to track its progress. Once it is launched, VisualGDB will ask to manually run the “xsdbserver start” command, copying the exact command to clipboard. Please try running it and once it completes, press OK in the VisualGDB prompt.

If XSCT crashes now, you will see the details directly in the command prompt window.

[support]

Thanks for checking this. If XSCT starts when launched manually, there could be a conflict with some environment variables set by VS.

Please try creating a new non-Xilinx project (e.g. Win32) and adding a custom pre-build step to launch cmd.exe in a new window (application: start, arguments: cmd.exe). Once you build that project, VisualGDB will launch a cmd.exe window using the same environment it would use for other processes.

Once that cmd window opens, please try running XSCT there and check if it works differently.

[support]

Thanks for checking this. Please try running the xsct.bat manually using the command line shown in the log:

 “C:\Xilinx\Vitis\2021.1\bin\xsct.bat” -n -interactive

once it starts, please try running the following command in its window:

xsdbserver start -host localhost -port 51971 ; puts done-b94d29f8-ead1-4873-b45a-629100933d4f

Finally, please try launching telnet and connecting to port 51971:

telnet localhost 51971

Does the telnet connection succeed?

[support]

Hi,

Looks like your toolchain is not compatible with your target. Please make sure you use a toolchain that exactly matches the OS running on the target (i.e. exactly the same SD card image).

[support]

Hi,

Most likely, you have changed some other setting as well. Please try reproducing the problem from scratch (i.e. from creating a new project).

If you can confirm that it occurs consistently, please share the complete instructions how to reproduce the problem from scratch per our problem reporting guidelines and we will try to investigate it further.

[support]

Hi,

No problem. Please try sharing the <Project directory>\.visualgdb\XSCT-Wizard.log file. It will show the XSCT commands executed by VisualGDB, and the responses from XSCT.

[support]

Hi,

No problem, we can help you understand what is going on.

When using the TinyEmbeddedTest framework, VisualGDB selects the tests to run as follows:

1. Sets a breakpoint in SysprogsTestHook_SelectTests()
2. Once it hits, evaluates testCount and pTests to get all available tests
3. Edits the array pointed by pTests (and updates testCount) to reflect the tests that were actually selected

These rules are stored in the <TestSelection> element in the TestFramework.xml file.

Most likely, something about your project structure (e.g. optimization) interferes with this. In order to get it working, we would advise trying to run the debugging normally and doing the test selection steps manually via the Watch window. If you run into issues (e.g. missing testCount variable), you may need to change the structure of your program to resolve them (e.g. declaring some variables static volatile if the compiler ends up optimizing them away).

Feel free to share the details about a workaround that worked and we will consider adding it on our side, unless it’s something specific to a particular project.

[support]

Hi,

Depending on your project type, the instrumentation settings (including real-time watch) can be stored per-configuration. If this is the case, you would need to configure them again after switching to a different configuration.

[Author]

Posts