Forum Replies Created
-
Posts
-
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.
Hi,
Sorry, this is by design. Instrumenting the image for profiling indeed changes its contents based on the exact instrumentation settings selected for a particular debugging session. As a workaround, please consider modifying the bootloader to temporarily suspend CRC checks during debug sessions (you can check whether a debugger is attached to an ARM chip via the debug module registers – see the your device documentation for more details).
No problem. Please feel free to run OpenOCD with gdb manually. If you can confirm that the debugging works outside VisualGDB, but doesn’t work with VisualGDB, we can definitely fix it.
Regarding the tests, we indeed run a few very basic tests on a few devices before releasing each OpenOCD package, but it doesn’t include programming FLASH memory on STM32L4.
In general, we provide the package mechanism so that our users would not need to locate the relevant code and build if from scratch. They are built automatically on our side with a few very basic tests, and are provided free of charge. Unfortunately, it not viable to extend our technical support to a huge code base maintained by thousands of external developers without directly charging for the time needed to investigate and fix these issues.
As mentioned before, please consider using VisualGDB with the J-Link software. It is maintained and tested by Segger and generally works more reliable than free OpenOCD.
