[support]

Hi,

Thanks for checking this. If avarice works from command line, but not with normal VisualGDB settings, it might be caused by some command line option (e.g. programming the FLASH). Please try comparing the manual command line with the command line shown in Visual Studio when launching the debug session (you can also see the command line via View->Other Windows->VisualGDB Diagnostics Console).

If the command line arguments are exactly the same, does switching VisualGDB debug method to “custom gdb stub” and hardcoding the command line change anything?

[support]

Hi,

You can update to any mbed version supported by VisualGDB (i.e. verified and repackaged by us) via Tools->VisualGDB->Manage VisualGDB Packages. The latest repackaged version so far is v5.6.3r3.

Once we release a package for 5.7.3, VisualGDB will automatically detect this and suggest updating it.

[support]

Hi,

Thanks for the screenshots. In v14.2 the setting was moved from a separate checkbox to another entry in the “Softdevice” combo box. Simply select “S132 (Programmed Separately)” for the same effect.

[support]

Hi,

No problem. If you are planning to debug some Linux-specific issues that involve custom gdb commands, you can use the GDB Session window in VisualGDB – it will let you run custom gdb commands as if you were using the regular command-line debugging experience and will automatically translate common commands (e.g. for setting breakpoints) to corresponding VisualGDB actions, so you can easily follow Linux-specific tutorials for those libraries with the full convenience of Visual Studio.

[support]

Hi,

Yes, please follow our OpenCV tutorial here: https://visualgdb.com/tutorials/raspberry/opencv/

[support]

Hi,

It should be still possible with 14.2. Simply select “No softdevice” or “Softdevice (Programmed separately)” on the first page of VisualGDB Project Properties.

If this doesn’t work, please attach a screenshot of the corresponding property page showing the expanded “Softdevice” combo box so we could check what is going on.

[support]

Hi,

Thanks for sharing this. It is indeed the correct way to specify those flags.

[support]

Hi,

Sorry for the delayed reply. We have tried reproducing this, however unfortunately could not get the behavior you are describing. Could you confirm that the problem occurs on a clean “Hello, World” project as well? If yes, could you please attach a screenshot of the “Import a folder recursively” window just before you click the “browse” button and the window that appears after you click it?

[support]

Hi,

As this is a fairly rare scenario, VisualGDB doesn’t offer a dedicated GUI setting for it, however the “Advanced Settings” section lets you customize the command line that VisualGDB will use when running the Segger GDB server. Please see the Segger documentation for an option that allows setting the JTAG scan chain position and explicitly add it to the command line in VisualGDB settings. If  you are not sure, please double-check it with Segger support, as they have a better knowledge of the Segger gdb stub internals.

Once you add the extra command line flag, you will still be able to use the regular VisualGDB settings (e.g. debug interface or FLASH programming mode).

[support]

Hi,

If we ever decided to retire VisualGDB, we would simply publish a DRM-free version that would not depend on our activation servers, just like Adobe did with the old Photoshop releases. However this isn’t going to happen in any foreseeable future – instead VisualGDB is actively growing and reaching out to new communities – the recently added advanced ESP-IDF project subsystem, the upcoming J-Trace and Arduino support, the planned improvements to the custom action subsystem and many more…

[support]

Hi,

Our regular support form will do.

[support]

Hi,

Thanks for sharing this. We haven’t tried OpenCV 3.4.1 yet, so it’s hard to say why it would use absolute paths, but we are planning to update our tutorial soon (also to show the new Advanced CMake project subsystem), so we will recheck this and include a 100% reliable workaround.

[support]

Hi,

This is likely our bug, however unfortunately it’s almost impossible to pinpoint it based on the message alone. Would you be able to attach a repro project so that we could investigate this further?

[support]

Hi,

Thanks for checking this. Looks like the only reasonable way to prevent OpenOCD from erasing those sectors would be to patch its source code. Another option would be to try Segger J-Link. Unlike the community-maintained OpenOCD, their gdb stub is covered by their support, so unless they already have an option for selective erase, they might be able to add it for you.

[support]

Hi,

Please enable verbose output via Tools->Options->VisualGDB and build the project. Then rename/delete one of the files and check the build output for the “Checking for previously transferred files that no longer exist…” line. If it is present in the build log, please let us know the subsequent lines. If not, please double-check that the .vgdbsettings file sets DeleteDisappearedFiles to true.

Also you can reproduce it on a basic “Hello, world” project, you can simply send it to us and we will investigate it on our side.

[Author]

Posts