Forum Replies Created
-
Posts
-
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.
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.
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?
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).
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.
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.
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:
- Sets a breakpoint in SysprogsTestHook_SelectTests()
- Once it hits, evaluates testCount and pTests to get all available tests
- 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.
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.
Hi,
Please contact our sales via the support form and we will get back to you with our rates and availability.
Hi,
It is possible to automatically import a project that is successfully building on the same machine with the same toolchain. Switching the project from being built on Raspberry Pi to being built with a cross-toolchain does require manual changes (typically, resynchronizing sysroot and updating all paths). We can gladly walk you through it, however as it’s not something that could be done automatically, it would be a subject to our consulting rate.
Hi,
Please note that VisualGDB does not change the original STM32CubeIDE project. If you believe this is not the case, 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.
Hi,
Most likely, you have selected an incompatible combination of settings at some point. If you can reproduce the problem reliably, please share the exact steps we could follow on our side from scratch to reproduce the problem, including all relevant screenshots per our problem reporting instructions and we will investigate it further.
Hi,
Instrumenting functions for profiling changes their timing and also increases the stack footprint (the code that outputs profiling information takes extra time and requires non-trivial amounts of stack). Most likely, in your scenario this triggers a stack overflow, or makes the interrupt handler run longer than the period between the interrupts.
Unfortunately, there is no fully automated way to troubleshoot such issues. Our best advice would be to try excluding some functions from instrumentation, and to experiment with increasing the stack size and decreasing the complexity of the affected functions.
