[support]

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.

[support]

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.

[support]

We are currently working on it an expect to release an updated BSP in the next few weeks.

[support]

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/

[support]

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

[support]

No problem. If you encounter any further issues, feel free to get back to us and we will be happy to help.

[support]

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.

 

[support]

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.

[support]

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.

[support]

It looks like you have started the Go-to command and than canceled it. The message can be safely ignored.

[support]

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.

[support]

Please check the following setting: Tools->Options->VisualGDB->Common->GUI->Use classic black and white color scheme for consoles.

[support]

No problem. We have rechecked the TFS integration with the latest VS build and it looks like the Arduino projects were indeed not handling it correctly.

Please try this build: VisualGDB-5.4.107.3206.msi

If the message still appears, please select the “Use solution binding” option. The SCC icons should now work.

In order to eliminate the message completely, please enable View->Other Windows->VisualGDB Diagnostics Console (using the new build), create a new project in a source-controlled directory and let us know:

1. Whether the lock icons appear after you created the project
2. If yes, whether they reappear after you reopen the solution
3. The full log from the Diagnostics Console showing the messages from creating and reopening the solution

[support]

No problem, please try this build: VisualGDB-5.4.107.3203.msi

[support]

Hi,

Most likely, some other program (e.g. CMake itself) is using that folder and hence it cannot be deleted.

This can normally be ignored, as VisualGDB will delete every file and subfolder that is not being used.

[Author]

Posts