Forum Replies Created
-
Posts
-
Hi,
Sorry, unfortunately the only case where the freeze/resume thread command is currently supported is kernel-mode debugging of multi-core devices via JTAG with VisualKernel where VisualKernel is fully controlling the status of each core. It is not supported for other debug sessions because the underlying gdb debugger does not support this functionality.
If gdb is extended in the future to support freezing/resuming of individual threads, we will add this functionality to VisualGDB as well.
It looks like something prevents Visual Studio from saving the solution file.
Please double-check that the solution is created and that the .sln file is writable and not open in any other application.
If this doesn’t help, please try creating another project/solution and check if the problem reoccurs. If not, please try comparing the working project to a non-working one (e.g. check whether placing the solution in a specific directory, or checking it into source control starts triggering the issue).
Hi,
Arduino would normally detect the libraries automatically based on the library directories. If this is not happening, please try narrowing the problem down to a specific library:
- Ensure that your .ino file includes the correct header file.
- Ensure that the library is located in one of the library directories (i.e. global per-user library folder, or a custom folder specified via VisualGDB Project Properties -> Arduino Library Directories).
If this doesn’t help, please try reproducing the problem with the same library on a freshly created project and share the exact steps from creating the project to observing library issues.
The “‘arduino:libraries’ is not found or not supported” error looks like TFS is trying to resolve a virtual path used by VisualGDB for the “Libraries” node in Solution Explorer. It should normally not cause any side effects and can be safely ignored.
It looks like VSS might expect some extra notifications from the Arduino projects. Please try narrowing it down to a specific sequence of actions that reliably triggers the problem and we will investigate it and try adding a workaround.
Sorry, currently the custom variables are indeed handled for each project separately.
We do have long-term plans for supporting property sheets that will allow sharing custom variable definitions between multiple projects.
As a workaround, please try using Windows environment variables instead. VisualGDB expands them same way as the project-level variables.
The link order to the object should not cause any issues because VisualGDB automatically uses the linker groups that instruct the linker to find symbols in every object inside the group.
Most likely, you have accidentally removed the implementation of HAL_SPI_Init() from your project. Please try searching all source files of the project for the “HAL_SPI_Init” text and ensure that the file implementing the function (i.e. providing a definition for it) is compiled and that the function implementation is not #ifdef-ed out.
You can read more about the differences between function declarations and definitions in the following tutorial: https://visualgdb.com/tutorials/tips/externc/
Thanks for the log file, it looks like our bug. We have fixed the problem in the following build: VisualGDB-5.4.108.3212.msi
No problem. If you encounter any further issues, feel free to get back to us and we will be happy to help.
Sorry about the attachment issues, we have updated our forum software to handle .log files properly.
Based on the log file, it looks like VisualGDB issues correct commands to gdb, but due to some reason, the RHEL gdb indeed ignores the watchpoint:
[ 595 ms] -break-watch *0x00007fffffffe9c8 [ 606 ms] ^done,wpt={number="2",exp="*0x00007fffffffe9c8"} [ 874 ms] *stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x000000000040063c",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffeab8"}],file="LinuxProject2.cpp",fullname="/tmp/VisualGDB/c/temp/LinuxProject2/LinuxProject2/LinuxProject2.cpp",line="3"},thread-id="1",stopped-threads="all",core="1" [ 4122 ms] -break-enable 2 [ 277085 ms] -exec-next [ 277098 ms] *stopped,reason="end-stepping-range",frame={addr="0x000000000040064a",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffeab8"}],file="LinuxProject2.cpp",fullname="/tmp/VisualGDB/c/temp/LinuxProject2/LinuxProject2/LinuxProject2.cpp",line="4"},thread-id="1",stopped-threads="all",core="1" [ 277555 ms] -exec-next [ 277566 ms] *stopped,reason="end-stepping-range",frame={addr="0x0000000000400652",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffeab8"}],file="LinuxProject2.cpp",fullname="/tmp/VisualGDB/c/temp/LinuxProject2/LinuxProject2/LinuxProject2.cpp",line="6"},thread-id="1",stopped-threads="all",core="1" [ 285940 ms] -exec-next [ 285952 ms] *stopped,reason="end-stepping-range",frame={addr="0x0000000000400657",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffeab8"}],file="LinuxProject2.cpp",fullname="/tmp/VisualGDB/c/temp/LinuxProject2/LinuxProject2/LinuxProject2.cpp",line="7"},thread-id="1",stopped-threads="all",core="1" [ 286862 ms] -exec-continue [ 286878 ms] *stopped,reason="watchpoint-trigger",wpt={number="2",exp="*0x00007fffffffe9c8"},value={old="0",new="-148686187"},frame={addr="0x00007ffff7233970",func="__run_exit_handlers",args=[],from="/lib64/libc.so.6"},thread-id="1",stopped-threads="all",core="1"This might be caused by some interference between watchpoints and stepping. Please try checking if pressing F5 after enabling the watchpoint instead of stepping through main() works.
We can also help you reproduce the problem within a command-line gdb session, so you could check with RHEL support whether they can offer some workarounds.
The stray semicolon and the About window text are fixed in the following build: VisualGDB-5.4.108.3210.msi
As we wanted to minimize the amount of users affected by the broken Arduino downloads, we released the R8 installer in a very short timeframe with minimal changes required to resolve the package download issue (properly skipping the empty URLs in the package downloading logic). The stray semicolon is indeed shown in the default settings for R8, however it no longer causes any problems.
The memory breakpoints are actually handled by the target itself. All VisualGDB can do is request gdb to set one.
Please try creating a gdb log as shown here, then check that the breakpoint is requested/set at the correct address and not disabled when it’s supposed to trigger.
Please also use the “x <address>” command in the GDB Session window after setting the breakpoint and after it is missed to verify that the memory has actually been modified.
If it looks like the address used by VisualGDB is incorrect, or the breakpoint is not set properly, we should be able to fix it. Otherwise, it could be a limitation of your toolchain. If you are not sure, please attach a gdb log here and we will help you understand what is going on.
It looks like you have started the Go-to command and than canceled it. The message can be safely ignored.
Sorry about that, looks like our test environment inherited the settings from the previous build and did not catch this.
We have released a hotfix (5.4r8) that fully fixes the issue. Thanks for reporting this.
